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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnectbn  of  computer  systems: 

a.  from  different  manufacturers. 

b.  under  different  management. 

c.  of  different  levels  of  complexity. 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  nK>re  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  fonn  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  OCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE.  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technotogy  -  Open  Systems  Interconnection  -  International  Standardized  Profiles 
12061-1:  OSI  Distributed  Transaction  Processing. 

Parti  INTRODUCTION 


1.  SCOPE 

Part  I  of  this  document  introduces  the  overall  structure  of  the  specification  of  the  OSI  TP  profiles. 
This  includes: 

a)  the  identification  of  the  Transaction  Processing  profiles  defined  in  this  document,  together 
with  the  Transaction  Processing  Profiles  Tree; 

b)  the  identification  of  the  various  Parts  which  constitute  this  document; 

c)  the  list  of  the  references  to  other  standards  relevant  to  the  definition  of  the  OSI  TP  profiles; 

d)  the  definKions  and  abbreviations  used  through  the  various  parts  of  this  document. 

2.  NORMATIVE  REFERENCES 

The  following  documents  contain  provisions  which,  through  reference  in  this  text,  constitute 
provisions  of  this  part  of  ISO/I  EC  ISP  1 2061 .  At  the  time  of  publication,  the  editions  indicated 
were  valid.  All  documents  are  subject  to  revision,  and  parties  to  agreements  based  on  this  part 
of  ISO/IEC  ISP  12061  are  warned  against  automatically  applying  any  more  recent  editions  of  the 
documents  listed  below,  since  the  nature  of  references  made  by  ISPs  to  such  documents,  is  that 
they  may  be  specific  to  a  particular  edition.  Members  of  lEC  and  ISO  maintain  registers  of 
currently  valid  International  Standards  and  ISPs,  and  CCITT  maintains  published  editions  of  its 
current  Recommendations. 

The  following  ISO  standards  contain  provisions  for  the  definition  of  Transaction  Processing 
profiles  and  are  referenced  in  this  document: 


ISO/IEC  8327^  Information  Processing  Systems  -  Open  Systems  Interconnection 

Basic  connection  oriented  session  protocol  specification 

ISO/IEC  DIS  8327-2       Infomriation  Processing  Systems  -  Open  Systems  Interconnection 

Basic  connection  oriented  session  PICS  Proforma. 

ISO/IEC  8327  AM3        Infomnation  Processing  Systems-  Open  Systems  Interconnection  - 

Session.  Additional  resynchronisation  functionality. 

ISO/IEC  8650  Information  Processing  Systems  -  Open  Systems  Interconnection 


Second  edition  to  be  published 
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ISO/IEC  DIS  8650-2 
ISO/IEC  8823:1988 
ISO/IEC  DIS  8823-2 
ISO/IEC  8823  AM5 
ISO/IEC  8825:1990 

ISO/IEC  9805-1:1990 

ISO/IEC  DIS  9805-2 
ISO/IEC  9805  AM2 
ISO/IEC  10026-1:1992 
ISO/IEC  10026-2:1992 
ISO/IEC  10026-3:1992 
ISO/IEC  DIS  10026-4 
ISO/IEC  11188-12 


Protocol  Specification  for  the  Association  Control  Service  Element. 

Information  Processing  Systems  -  Open  Systems  Interconnection  - 
PICS  Proforma  for  the  Association  Control  Sen/ice  Element. 

Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Connection  Oriented  Presentation  Protocol  Specification. 

Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Connection  Oriented  Presentation  PICS  Proforma. 

Information  Technology  -  Open  Systems  Interconnection  - 
Presentation.  Additional  resynchronisation  functionality. 

Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation 
One  (ASN.1). 

Information  Technology  -  Open  Systems  Interconnection  -  Protocol 
Specification  for  the  Commitment,  Concurrency  and  Recovery  sen/ice 
element. 

Information  Technology  -  Open  Systems  Interconnection  -  CCR  PICS 
Proforma. 

Information  Technology  -  Open  Systems  Interconnection  -  CCR. 
Session  mapping  changes. 

Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing:  Model. 

Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing:  Service  Definition. 

Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing:  Protocol  Specification. 

Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing:  PICS  Proforma 

Information  Technology  -  International  Standardized  Profile-  Common 
Upper  Layer  Requirements 


2  Cun-ently  a  regional  workshop  document 
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3.       DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  in  this  document  not  listed  in  this  section  are  found  in  the  TP 
model  document  (ISO/IEC  10026-1). 


AS- 

Conformance  class  for  Application  Supported  Transaction 

CP- 

Conformance  class  for  Chained  Provider  Supported  Transaction  Branches 

UP- 

Conformance  class  for  Unchained  Provider  Supported  Transaction  Branches 

FU- 

Functional  Unit 

ISP- 

International  Standardized  Profile 

PDU- 

Protocol  Data  Unit 

PPDU- 

Presentation  Protocol  Data  Unit 

SPDU- 

Session  Protocol  Data  Unit 

The  following  notations  are  used  in  the  tables  contained  in  Parts  2  to  4  of  this  ISP: 

1)  The  Item  Number  uniquely  identifies  each  capability,  parameter  or  field  within  the 
tables. 

2)  The  Parameter  column  provides  the  name  of  each  PDU  parameter. 

3)  The  Base  Standard  Status  column  indicates  static  requirements  as  defined  by  the 
base  standard  PICS  Proforma. 

The  notation  used  in  this  column  is  as  defined: 

-  in  the  OSI  TP  and  CCR  PICS  proforma  documents  for  the  OSI  TP  and  CCR 
related  tables; 

-  in  the  "Common  Upper  Layer  Requirement"  document  for  ACSE,  Presentation  and 
Session  related  tables. 

However,  as  the  ISP  is  not  intended  to  duplicate  the  information  contained  in  the 
documents  listed  above,  the  notation  has  been  simplified  as  follows: 

-  "C"  is  used  instead  of  any  "Cxxx",  where  xxx  is  an  integer. 

-  "O.n"  is  used  instead  of  any  "O.xxx",  where  xxx  is  an  integer. 

The  exact  definition  of  conditions  and  options  will  be  found  in  the  referenced 
documents. 

Note  that  the  "M"  and  "0"  notations  have  not  been  changed. 

Note  that  the  "D"  (default)  notation  may  be  used  in  this  column,  whilst  it  is  not  used 

in  the  PROFILE  Status  column  (included  within  the  M  notation). 

4)  The  Profile  ID  column,  if  present,  defines  how  this  parameter  is  used  by  a  specific 
profile. 

When  this  column  is  empty,  the  feature  applies  to  all  profiles  to  which  the  PDU 
applies. 

5)  The  Profile  Status  column  indicates  the  requirements  for  the  feature. 

These  requirements  are  valid  only  within  the  scope  of  a  specific  profile,  i.e.,  they 
apply  to  an  instance  of  an  implementation  operating  within  the  limits  specified  by  that 
profile.  For  instance,  the  notation  NA  used  for  some  feature  does  not  preclude  an 
implementation  from  supporting  more  than  one  profile. 

M  =   Mandatory.  The  feature  shall  be  supported,  i.e.  its  syntax  and  procedures 
shall  be  implemented  as  specified  in  the  base  standard  or  restricted  by  this 
ISP,  by  all  implementations  claiming  conformance  to  this  profile.  It  is  not 
necessary  that  a  mandatory  parameter  appears  in  all  instances  of 
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communication  when  either  a  detault  value  has  been  specified,  or  this 
parameter  is  not  used  at  the  service  level. 

C  =    Conditional.  Any  feature  so  marked  must  be  inriplemented  under  the 

conditions  specified  in  the  profile  (e.g.  Mandatory,  Not  Applicable,  etc.,  for  a 
certain  instance  of  communication).  The  requirements  for  the  feature  then 
follow  the  rules  of  M,  NA,  etc. 

0  =    Optional.  This  is  an  optional  feature  in  the  base  standard.  It  is  left  to  the 

implementor  as  to  whether  this  feature  is  implemented.  Optional  features  for 
a  sender  need  not  be  implemented.  Optional  features  for  a  receiver  must  be 
recognized  and  may  be  processed  in  a  manner  consistent  with  the  base 
standard,  or  these  profiles.  If  implemented,  a  feature  will  be  subject  to 
conformance  testing. 

NA  =  Not  Applicable.  This  feature  is  not  defined  in  the  context  where  it  is 

mentioned  because  it  is  either  logically  or  physically  impossible  for  the  feature 
to  occur.  The  occurrence  of  this  feature  is  a  protocol  error.  It  will  be  handled 
as  specified  in  the  base  standard  or  this  ISP. 

1  =     Out  of  Scope.  This  is  an  optional  feature  of  a  base  standard.  However,  this 

feature  is  not  used  by  the  profile  nor  by  a  referencing  specification.  If  such  a 
feature  is  received  it  is  processed  according  to  local  procedures.  Local 
procedures  are  procedures  that  are  not  defined  by  any  base  standards  or 
profiles.  It  will  not  generate  a  protocol  error. 

There  are  presently  some  instances  where  features  marked  'M'  in  the  base 
standard  are  marked  T  in  this  profile.  This  has  been  done  only  because  the 
base  standard  PICS  are  not  yet  at  full  international  standard  status  and  it  is 
believed  that  the  markings  of  the  feature  will  change  during  progression  to  full 
international  standard  status.  It  is  intended  to  remove  all  such  inconsistencies 
with  the  base  standard  before  publication  of  this  ISP. 

*  =  U-ASE  defined.  This  is  an  optional  feature  of  a  base  standard.  This  feature 
may  or  may  not  be  used  by  a  referencing  specification.  How  it  is  used  is 
specified  by  the  referencing  specification.  When  a  default  value  is  given  in 
this  profile,  the  referencing  specification  may  choose  not  to  specify  any  value 
in  which  case,  the  default  value  applies.  A  default  value  is  specified  in 
parentheses  following  the  *,  e.g.,  *(l). 

O.N=  The  notation  O.N,  where  N  is  an  integer,  is  used  in  some  Status  Columns. 
This  notation  indicates  a  reference  to  a  unique  group  of  capabilities.  A  note 
(as  indicated  in  the  Notes  Column)  will  explain  the  exact  requirement  using 
one  of  the  following  forms: 

O.N  =  Support  of  exactly  one  of  these  items  is  required. 

O.N  =  Support  of  at  least  one  of  these  items  is  required. 
It  is  always  necessary  to  consult  the  corresponding  note  to  determine  which 
situation  applies. 

When  status  for  sending  and  receiving  values  differ,  they  will  be  separated  by  a 
slash,  with  the  sender  on  the  left  and  receiver  on  the  right.  If  they  are  the  same 
there  will  only  be  one  status  in  the  cell.  The  integer  suffix  to  a  status  refers  to  a 
condition  that  will  be  found  either  immediately  following  that  table,  or  following  an 
earlier  table  in  the  same  part  of  this  ISP. 
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6)  The  T/L/V  Allowed  column  specifies  the  range  of  types,  length,  or  values  this 
parameter  can  assume  or  contain.  This  column  can  have  multiple  definitions  based 
on  which  profile  is  being  described.  When  multiple  definitions  are  possible  this 
column  will  be  defined  in  conjunction  with  the  Profile  ID  column.  The  notation  {} 
denote  no  bits  in  the  parameter's  value. 

7)  The  Notes  column  points  to  notes  following  the  table. 
5.       TAXONOMY  STRUCTURE 

5.1.    GUIDELINES  FOR  SPLITTING  UP  THE  PROFILES 

This  subclause  specifies  which  functional  units  combine  to  form  each  profile.  Refer  to  the 
appropriate  part  of  this  ISP  for  the  specification  of  how  a  specific  profile  uses  a  PDU  and  its 
parameters.  Profiles  are  identified  by  a  coding  method  which  consists  of  two  levels,  but  which 
can  easily  be  expanded  as  future  needs  warrant.  The  first  level  indicates  the  conformance  class. 
The  second  level  indicates  whether  polarized  or  shared  control  is  used.  The  levels  are  defined 
as: 

Level  one: 

1 .  -  Application  Supported  transactions. 

2.  -  Provider  supported  unchained  transactions. 

3.  -  Provider  supported  chained  transactions. 

Level  two: 

1 .  -  Polarized  control. 

2.  -  Shared  control. 

5.2     TRANSACTION  PROCESSING  PROFILES  TREE 

The  figure  hereafter  gives  the  Transaction  Processing  Profiles  tree: 


Transaction  Processing 

ATP 

Application  Supported  Transactions 

ATPl 

Polarized  Control 

ATPll 

Shared  Control 

ATPl  2 

Provider  Supported  Unchained  Transactions 

ATP2 

Polarized  Control 

ATP21 

Shared  Control 

ATP22 

Provider  Supported  Chained  Transactions 

ATP3 

Polarized  Control 

ATP31 

Shared  Control 

ATP32 

The  first  level  of  this  decomposition  (ATPx)  corresponds  to  the  definition  of  the  three 
conformance  classes  defined  in  the  OSI  TP  standard.  The  second  level  (ATPxy)  corresponds  to 
the  selection  between  Polarized  Control  and  Shared  Control  for  each  of  the  conformance 
classes.  The  conformance  classes  and  the  functional  units  that  compose  them  are  summarized 
in  the  following  list: 
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1  ATP-1 1  Application  Supported  Transactions  -  Polarized  Control: 
DIALOGUE  +  HANDSHAKE  +  POLARIZED  CONTROL 

2  ATP-21  Provider  Supported  Unchained  Transactions  -  Polarized  Control: 
DIALOGUE  +  HANDSHAKE  +  POLARIZED  CONTROL  +  COMMIT  +  RECOVERY  + 
UNCHAINED  TRANSACTION 

3.  ATP-31  Provider  Supported  Chained  Transactions  -  Polarized  Control: 
DIALOGUE  +  HANDSHAKE  +  POLARIZED  CONTROL  +  COMMIT  +  RECOVERY  + 
CHAINED  TRANSACTION 

4.  ATP-1 2  Application  Supported  Transactions  -  Shared  Control: 
DIALOGUE  +  HANDSHAKE  (Optional)  +  SHARED  CONTROL 

5.  ATP-22  Provider  Supported  Unchained  Transaction  -  Shared  Control: 

DIALOGUE  +  HANDSHAKE  (Optional)  +  SHARED  CONTROL  +  COMMIT  +  RECOVERY  + 
UNCHAINED  TRANSACTION 

6.  ATP-32  Provider  Supported  Chained  Transactions  -  Shared  Control: 

DIALOGUE  +  HANDSHAKE  (Optional)  +  SHARED  CONTROL  +  COMMIT  +  RECOVERY  + 
CHAINED  TRANSACTION 


Since  the  Profile  ID  is  not  carried  as  a  protocol  paranieter,  implementations  may  determine  the 
profile  governing  a  particular  instance  of  communication  by  the  TP  Functional  Units  selected  for 
that  dialogue. 

6.  CONFORMANCE 

This  part  of  ISO/I  EC  ISP  12061  states  requirements  upon  implementors  to  achieve  inter 
networking.  A  claim  of  conformance  to  one  of  parts  five  to  ten  of  this  ISP  is  a  claim  that  all 
requirements  in  the  relevant  base  standards  are  satisfied,  and  that  all  requirements  in  the 
relevant  parts  are  satisfied. 

Annexes  to  parts  two,  three  and  four  state  the  relationship  between  these  requirements  and 
those  of  the  base  standard. 

There  is  no  conformance  requirement  from  this  ISP  on  features  marked     in  the  annexes  of 
parts  two  and  four. 

Each  of  parts  five  to  ten  contain  specific  conformance  requirements  for  that  part. 


December  1992  (Stable) 
PDISP  12061-1 
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INTRODUCTION 


The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement 
outside  the  interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as 
transactions,  which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems 
Interconnection  (OSI)  a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by 
four  properties:  atomicity,  consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of 
messages,  but  that  the  exchanges  form  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified 
in  M-IT-02  and  TR  10000. 


Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 


Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles 
specified  in  Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  OCR  APDUs  for  each  of  the 
profiles  specified  in  Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session 
APDUs  for  each  of  the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard. 
These  six  parts  make  reference  to  Parts  2  to  4. 
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Part  1 5  -  Transaction  Processing  December  1 992  (Stable) 
TP  PDISP  12061-2 

1.  SCOPE 

This  part  of  this  ISP  specifies  the  status  for  the  support  of  the  OSI  TP  protocol  for  the  profiles 
identified  in  Part  1  of  this  ISP. 


2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  contained  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  NOTATION 

The  notation  introduced  in  Part  1  of  this  ISP  applies  to  this  Part. 

5.  SUPPORT  OF  OSI  TP  PROTOCOL 

The  support  of  the  OSI  TP  protocol  is  as  described  in  Annex  A  (normative). 

The  structure  of  Annex  A  is  based  on  the  structure  of  Annex  A  of  ISO/IEC  10026-4,  In  particular 
in  the  numbering  of  the  clauses. 

When  a  clause  of  Annex  A  of  ISO/IEC  1 0026-4  is  not  relevant  to  the  profiles,  this  is  stated. 

6.  Conformance 

To  conform  to  the  OSI  TP  Protocol  used  in  any  of  the  profiles  in  this  ISP,  an  implementation  shall 
implement,  according  to  the  specifications  given  in  ISO/IEC  10026-3: 

1 .  All  the  mandatory  features  identified  in  Annex  A. 

2.  All  the  selected  optional  features,  as  identified  in  the  completed  TP  PICS. 
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ANNEX  A:  SUPPORT  OF  THE  OSI  TP  PROTOCOL  (Normative) 
A.I.  IDENTIFICATION 

No  restriction  is  applied  to  clause  A.I  of  ISO/IEC  10026-4  by  this  part  of  ISO/IEC  ISP  1 2061 . 
A.2.  CLAIMED  CONFORMANCE  TO  STANDARDS 

A.2.1.  ISO/IEC  10026-3 

A.2.1 .1 .         VERSION  NUMBER(S) 

Answer  shall  be  "NONE". 

A.2.1 .2.         GLOBAL  CONFORMANCE  CLAIM 

Answer  shall  be  "YES". 

A.2.2.  ISO/IEC  10026  AMENDMENTS 

Both  answers  shall  be  "NONE". 

A.2.3.  ISO/IEC  10026  TECHNICAL  CORRIGENDA 

Both  answers  shall  be  "NONE". 

Note:  At  the  time  of  the  approval  of  the  final  text  of  this  ISP,  no  Technical  Corrigenda  was 
approved  for  ISO/IEC  10026.  When  this  will  become  false,  the  present  ISP  will  be  connected 
accordingly. 
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A.2.4.  CONFORMANCE  CLASS(ES)  SUPPORTED 

Table  1  -  CONFORMANCE  CLASSES  SUPPORTED 


ITEM# 

CONFORMANCE  CLASSES 

ISO/IEC 
10026^ 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Application  Transaction  Branches 

O 

M 

NA 

NA 

M 

NA 

NA 

2 

Chained  Provider  Supported  Transaction 
Branches 

O 

NA 

NA 

M 

NA 

NA 

M 

3 

Unchained  Provider  Supported  Transaction 
Branches 

0 

NA 

M 

NA 

NA 

M 

NA 

NOTES 


Conformance  to  more  than  one  profile  may  be  claimed  for  an  implementation.  For  example, 
an  implementation  that  conforms  to  profile  21  will  often  be  capable  of  conforming  to  the 
corresponding  Profile  1 1 . 
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A.3.  FUNCTIONAL  UNITS,  LIMITS  AND  PROTOCOL  MECHANISMS 
A.3.1 .  SUPPORT  OF  FUNCTIONAL  UNITS 

Table  2  -  SUPPORT  OF  FUNCTIONAL  UNITS 


ITPM  M 

PUNCTIONAL  UNITS 

ISO/IEC  10026-4 

11 

21 

1 

31 

'ROFIL 
12 

:S 
22 

32 

NOTES 

AS 

CP 

UP 

1 

Dialogue 

M 

M 

M 

M 

M 

M 

M 

M 

M 

2 

Shared  Control 

O.n 

O.n 

On 

NA 

NA 

NA 

M 

M 

M 

3 

Polarized  Control 

O.n 

O.n 

On 

M 

M 

M 

NA 

NA 

NA 

4 

Handshake 

O 

O 

0 

M 

M 

M 

O 

O 

O 

5 

Commit 

NA 

M 

M 

NA 

M 

M 

NA 

M 

M 

6 

Chained  Transactions 

NA 

M 

NA 

NA 

NA 

M 

NA 

NA 

M 

7 

Unchained  Transactions 

NA 

NA 

M 

NA 

M 

NA 

NA 

M 

NA 

e 

Recovery 

NA 

M 

M 

NA 

M 

M 

NA 

M 

M 

A.3.2.   PROTOCOL  MECHANISMS  IMPLEMENTED 
A.3.2.1 .  CONCATENATION/SEPARATION 

Table  3  -  SUPPORT  FOR  CONCATENATION/SEPARATION 


ITEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Concatenation 

O 

O 

0 

O 

O 

O 

O 

2 

Separation 

M 

M 

M 

M 

M 

M 

M 
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A.3.2.2.         ASSOCIATION  ESTABLISHMENT 


Table  4  -  ASSOCIATION  ESTABLISHMENT 


iTEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator 

C 

0 

M 

M 

O 

M 

M 

1.2.4 

2 

Acceptor 

0 

O 

M 

M 

O 

M 

M 

1.3.4 

3 

Rejector 

0 

M 

M 

M 

M 

M 

M 

5.6 

NOTES 


1  When  the  commitment  is  supported,  then  the  implementation  must  be  able  to  support  both 
the  association  initiator  and  acceptor  role  in  order  to  be  able  to  perform  recovery  adequately. 

2  The  initiator  role  here  implies  being  capable  of  issuing  an  A-ASSOCIATE  request  and  being 
capable  of  receiving  an  A-ASSOCIATE  confirm. 

3  The  Acceptor  role  here  implies  being  capable  of  receiving  an  A-ASSOCIATE  indication  and 
being  capable  of  issuing  an  A-ASSOCIATE  response  with  a  positive  answer. 

4.  For  Profiles  1 1  and  12,  at  a  minimum,  the  association  establishment  initiator  role  or  the 
association  establishment  acceptor  role  shall  be  supported. 

5.  The  Rejector  role  here  implies  being  capable  of  receiving  an  A-ASSOCIATE  indication  and 
being  capable  of  issuing  an  A-ASSOCIATE  response  with  a  negative  answer. 

6.  Although  it  is  mandatory  to  be  able  to  reject  an  association,  note  that  in  some  particular 
environments  it  could  occur  that  the  reject  is  always  performed  by  some  lower  protocol 
machine  (e.g.  ACSE). 
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A.3.2.3.         SUPPORT  FOR  MANDATORY  AND  OPTIONAL  BIDDING 
Table  5  -  SUPPORT  FOR  MANDATORY  AND  OPTIONAL  BIDDING 


ITEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator  with 
Bid  mandatory 

c 

ClOO 

M 

M 

C100 

M 

M 

2 

Initiator  with 
Bid  optional 

c 

C101 

O 

O 

C101 

O 

0 

3 

Responder  with 
Bid  mandatory 

c 

0102 

M 

M 

C102 

M 

M 

4 

Responder  with 
Bid  optional 

c 

C103 

M 

M 

C103 

M 

M 

100  If  the  Initator  of  an  association  role  is  supported(A.3.2.2/1)  then  0  else  NA. 


101  If  the  initiator  of  the  association  role  is  supported  (A.3.2.2/1)  then  M  else  NA. 

102  If  the  Acceptor  of  an  Association  role  is  supported(A.3.2.2/2)  then  0  else  NA. 

103  If  the  Acceptor  of  an  Association  role  is  supported(A.3. 2.2/2)  then  M  else  NA. 
A.3.2.4.  CONTENTION 


Table  6  -  SUPPORT  FOR  CONTENTION  MANAGEMENT 


ITEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Contention  Winner 

On 

O 

M 

M 

O 

M 

M 

1.2 

2 

Contention  Loser 

O.n 

0 

M 

M 

O 

M 

M 

1.2 

NOTES 

1 .  When  the  commitment  is  supported,  in  order  to  enable  channel  establishment  (initiator  or 
acceptor)  to  be  accepted,  it  is  required  to  be  able  to  support  both  the  contention  winner  and 
contention  loser  roles. 

2.  For  profiles  1 1  and  1 2,  at  least  one  of  the  contention  winner  and  contention  loser  roles  shall 
be  supported. 
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A.3.2.5.         BID  MECHANISM 


Table  7  -  SUPPORT  FOR  THE  BID  MECHANISM 


ITEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator 

0 

C105 

M 

M 

0105 

M 

M 

1.3 

2 

Responder 

0 

0106 

M 

M 

0106 

M 

M 

2.3 

105  if  the  Contention  Loser  role  is  supported  (A.3.2.4/2)  then 

If  Associations  with  Bid  Mandatory  are  supported  (A.3.2.3/1  or  A.3.2.3/3) 
then  M  else  O 
else  NA 


1 06  If  the  Contention  Winner  role  is  supported  (A.3.2.4/1 )  then  M  else  N A 

NOTES 

1 .  The  initiator  role  here  implies  being  capable  of  sending  a  TP-BID-RI APDU  and  being 
capable  of  receiving  a  TP-BID-RC  APDU. 

2.  The  responder  role  here  implies  being  capable  of  receiving  a  TP-BID-RI  APDU  and  being 
capable  of  sending  a  TP-BID-RC  APDU  with  a  positive  answer. 

3.  When  the  commitment  is  supported,  in  order  to  enable  channel  establishment  (initiator  and 
acceptor)  to  be  accepted,  it  is  required  to  be  able  to  support  both  the  bid  initiator  and  bid 
responder  roles. 

A.3.2.6.         DIALOGUE  ESTABLISHMENT 

Table  8  -  TP  DIALOGUE  ESTABLISHMENT 


ITEM« 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

11 

Initiator 

On 

0 

O 

O 

O 

O 

O 

1.3 

2 

Acceptor 

On 

o 

O 

0 

0 

0 

O 

2.3 

3 

Rejector 

M 

M 

M 

M 

M 

M 

M 

NOTES 


1 .  The  initiator  role  here  implies  being  capable  of  sending  a  TP-BEGIN-DIALOGUE-RI  APDU 
and  being  capable  of  receiving  a  TP-BEGIN-DIALOGUE-RC  APDU. 
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2.  The  Acceptor  role  here  implies  being  capable  of  receiving  a  TP-BEQIN-DIALOGUE-RI  APDU 
and  being  capable  of  sending  a  TP-BEGIN-DIALOGUE-RC  APDU  with  a  positive  answer. 

3.  For  each  of  the  profiles.at  least  one  of  the  Acceptor  or  initiator  roles  shall  be  implemented. 
A.3.2.7.         TRANSACTION  BRANCH  ESTABLISHMENT 


Table  9  -  TRANSACTION  BRANCH  ESTABLISHMENT 


ITEM* 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator 

c 

NA 

0107 

0107 

NA 

0107 

0107 

2 

Acceptor 

c 

NA 

C108 

0108 

NA 

0108 

0108 

107  If  the  implementation  is  capable  of  initiating  a  dialogue  (A.3.2.6/1)  then  M  else  NA. 

108  If  the  implementaion  is  capable  of  accepting  a  dialogue  (A.3.2.6/2)  then  M  else  NA. 
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A.3.2.8.         ROLES  IN  A  TRANSACTION  TREE  SUPPORTED 
Table  10  -  ROLES  IN  A  TRANSACTION  TREE  SUPPORTED 


iTEM# 

ROLE 

SSO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Root^k)de 

C 

NA 

O 

O 

NA 

O 

O 

1 

2 

Intermediate  Node 

0 

NA 

O 

O 

NA 

O 

O 

1 

3 

Leaf  Node 

c 

NA 

0109 

0109 

NA 

0109 

0109 

1 

109  If  capable  of  acting  as  an  intermediate  node  then  M  else  O. 
NOTES 

1 .  An  implementation  must  be  capable  of  acting  as  either  a  root,  an  intermediate  or  a  leaf 
node. 

A.3.2.9.         SUPPORT  FOR  RECOVERY 

This  clause  does  not  apply  to  profiles  1 1  and  1 2. 


Table  11  -  SUPPORT  FOR  RECOVERY 


ITEM# 

ROLE 

ISO/lEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

One-Way 
recovery 

M 

NA 

M 

M 

NA 

M 

M 

2 

Two-Way 
Recovery 

O 

NA 

O 

0 

NA 

O 

O 
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A.4.  TP  PROTOCOL  -  GENERAL 

The  clause  A.4  in  ISO/IEC  1 0026-4  is  not  relevant. 

A.5.  TP  PROTOCOL  -  SUPPORT  OF  THE  DIALOGUE  FUNCTIONAL  UNIT 
A.5.1.   DIALOGUE  FU  APDUS 


Table  12  -  TP  APDUS  FOR  THE  DIALOGUE  FU 


ITEM# 

PROTOCOL  DATA  UNIT 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-BEGIN-DIALOGUE-RI 

C 

C107/ 
M 

CI  07/ 
M 

C107/ 
M 

C107/ 
M 

C107/ 
M 

C107/ 
M 

1 

2 

TP-BEGIN-DIALOGUE- 
RC 

C 

M/ 

C107 

M/ 

C107 

C107 

M 

C107 

M/ 

C107 

M/ 

C107 

2 

3 

TP-END-DIALOGUE-RI 

C 

M 

M 

NA 

M 

M 

NA 

4 

TP-END-DIALOGUE-RC 

C 

M 

M 

NA 

M 

M 

NA 

5 

TP-U-ERROR-RI 

M 

M 

M 

M 

M 

M 

M 

6 

TP-ABORT-RI 

M 

M 

M 

M 

M 

M 

M 

7 

TP-BID-RI 

C 

cm/ 

Clio 

M 

M 

cm/ 

Clio 

M 

M 

8 

TP-BID-RC 

C 

C110/ 

cm 

M 

M 

Clio/ 

cm 

M 

M 

9 

TP-INITIALIZE-RI 

C 

C112/ 
M 

M 

M 

C112/ 
M 

M 

M 

3 

10 

TP-INITIALIZE-RC 

C 

M/ 

C112 

M 

M 

M/ 

C112 

M 

M 

4 

1 10  If  the  implementation  is  capable  of  receiving  a  Bid  (A.3.2.5/2)  then  M  else  NA 

1 1 1  If  the  implementation  is  capable  of  initiating  a  Bid  (A.3.2.5/1)  then  M  else  NA 

1 12  If  the  implementation  is  capable  of  initiating  an  association  (A.3.2.2/1)  then  M  else  NA 

NOTES 

1 .   It  is  mandatory  for  every  implementation  to  receive  and  recognize  the  TP-BEGIN- 
DIALOGUE-Rl  APDU  (ref  ISO/IEC  10026-3  13.1. 2.1. c  and  13.1. 2.1  .f). 
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2.  It  is  mandatory  for  every  implementation  to  be  capable  of  rejecting  a  TP-BEGIN-DIALOGUE- 
Rl  (ref  ISO/IEC  10026-3  13.1.2.1f) 

3.  It  is  mandatory  for  every  implementation  to  receive  and  recognize  the  TP-INITIALIZE-RI 
APDU  (ref  ISO/IEC  10026-3  13.1. 2.1. a). 

4.  It  is  mandatory  for  every  implementation  to  be  capable  of  rejecting  a  TP-INITIALIZE-RI 
APDU 


12 


Part  15  -  Transaction  Processing 
TP 


December  1992  (Stable) 
PDISP  12061-2 


A.5.2.  TP-BEGIN-DIALOGUE-RI  APDU 

A.5.2.1.         DETAIL  OF  THE  DIALOGUE  FIELD  OF  TP-BEGIN-DIALOGUE- 
Rl  APDU 

Table  13  -  TP-BEGIN-DIALOGUE-RI  for  Dialogue 


ITCM  it 
i  1  CM  # 

ISO/IEC  10026-4 

PROFILE 

DA  D  AkflCTCD 

PARAMcTcn 

ex  ATI  le 
STATUS 

ex  A  XI  lo 
9 1 A 1  Uo 

X/l  /U  All  ^lAicn 

NOTcS 

1 

inltiating-TroU- Title 

O/M 

M 

see  laoie  14 

Redpient-TPSU-Title 

O/M 

ft  J 
M 

see  Table  14 

o 
O 

runcuonai-uniis 

p* 
u 

1 1 

M 

10.4} 

12 

M 

{1}  OR  {1.4} 

21 

M 

tf\  O  ill 

{0.3,4} 

oo 

ex. 

M 

11  11  nr  f1  1 
\  1 .0/  Or  \  1  .o.4| 

31 

y 

{0.2,4} 

32 

M 

{1,2}  or  {1.2.4} 

4 

Begin-Transaction 

C 

11.12.31.32 

NA 

21.22 

M 

5 

Confirmation 

D 

M 

6 

Correlator 

M 

M 

0.2**31-1 

7 

Last-Partner-Identifier 

O/M 

M 

0.2**31-1 

1 

8 

User-Data 

O/M 

M 

0..10K  octets+ 

2 

NOTES 

1 .  The  Last-Partner- Identifier  is  marked  M  because  an  implementation  shall  be  able  to  support 
more  than  one  dialogue  or  channel  on  an  association. 

2.  The  receiver  shall  be  capable  of  receiving  at  least  1 0K  octets  of  user-data. 


13 


A.5.2.1 .1 .       DETAIL  OF  TPSU-TITLE  FIELDS  FOR  THE  DIALOGUE  FIELD 
OF  TP-BEGIN-DIALOGUE-RI  APDU 

Table  14  -  Detail  of  TPSU-TITLE  fields  for  the  dialogue  field  of  TP-BEGIN-DIALOGUE-RI 

APDU 


ITEM# 

ISO/IEC  10026-4 

PROFI 

LE 

TYPE 

STATUS 

PROFILE  ID 

STATUS 

T/IJV  ALLOWED 

NOTES 

1 

T61  String 

O.n/M 

C113/M 

1.. 64  octets 

1 

2 

PrintableString 

O.n/M 

C113/M 

1.64  octets 

1 

3 

INTEGER 

O.n/M 

C113/M 

0..2"31-1 

1 

113  If  the  TPSU-TITLE  is  used  to  carry  a  RECIPIENT-TPSU-TITLE  value  then  M  else  0 
NOTES 

1 .  At  least  one  of  the  three  types  shall  be  supported  for  the  INITIATING-TPSU-TITLE. 


A.5.3.  TP-BEGIN-DIALOGUE-RC  APDU 

A.5.3.1.         DETAIL  OF  THE  DIALOGUE  FIELD  OF  TP-BEGIN-DIALOGUE- 
RC  APDU 

Table  15  -  TP-BEGIN-DIALOGUE-RC  for  Dialogue 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/IJV  ALLOWED 

NOTES 

1 

Functional-Units 

O/M 

M 

2 

Result 

D 

M 

3 

Diagnostic 

M 

M 

4 

Correlator 

M 

M 

0..2**31-1 

5 

User- Data 

O/M 

M 

0..10K  octets+ 

1 

NOTES 

1 .  The  receiver  shall  be  capable  of  receiving  at  least  10K  octets  of  user-data 
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A.5.4.  TP-END-DIALOGUE-RI  APDU 

This  APDU  does  not  apply  to  profiles  31  and  32. 

Table  16  -  TP-END-DIALOGUE-RI  for  Dialogue 


ITEM* 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Confirmatjon 

D 

11,12.21,22 

M 

A.5.5.  TP-ABORT-RI  APDU 

A.5.5.1 .         DETAIL  OF  THE  USER  FIELD  OF  TP-ABORT-RI  APDU 

Table  17  -  TP-ABORT-RI,  for  user 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

User-Data 

0/M 

M 

0..10K  octets  + 

1 

NOTE 

1 .  The  receiver  shall  be  capable  of  receiving  at  least  1 0K  octets  of  user-data 

A.5.5.2.         DETAIL  OF  THE  PROVIDER  FIELD  OF  TP-ABORT-RI  APDU 


Table  18  -  TP-ABORT-RI,  for  provider 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Provider-diagnostic 

M 

M 
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A.5.5.3.         TP-BID-RI APDU 

Table  19 -TP-BID-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUV  ALLOWED 

NOTES 

1 

CO  R-Token-  Requested 

D 

11,12 

M 

False 

21,22,31,32 

M 

2 

Last-Partner-Identifier 

0/M 

M 

0..2"3M 

A.5.6.  TP-BID-RC  APDU 

Table  20  -  TP-BID-RC 

ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Result 

D 

M 

A.5.7.   TP-INITIALIZE-RI  APDU 

Table  21  -  TP-INITIALIZE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Protocol-Version 

D 

M 

{version  1} 

2 

Contention- Winner-Assignment 

D 

M 

3 

Bid- Mandatory 

D 

M 

4 

Recovery-Context-Handle 

C 

11,12 

1 

21,22.31,32 

0/M 

1..64  octets 

1 

NOTES 

1  It  is  optional  to  send  a  RECOVERY-CONTEXT-HANDLE  (RCH)  as  the  sender  may  have  no 
use  for  it.  It  is  mandatory  to  receive  an  RCH  and  be  able  to  send  it  on  the  TP-RECOVER-RI 
APDU. 

1 


16 


Part  15  -  Transaction  Processing 
TP 


December  1992  (Stable) 
PDISP  12061-2 


A.5.8.  TP-INITiALIZE-RC  APDU 

Table  22  -  TP-INITIALIZE-RC 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Protocol- Version 

D 

M 

{version  1} 

2 

Reoovery-Context-Handle 

O/M 

11.12 

1 

21.22.31.32 

O/M 

1..64  octets 

1 

3 

Diaqnostic 

0/M 

M 

NOTES 


1    It  is  optional  to  send  a  Recovery-Context-Handle  (RCH)  as  the  sender  may  have  no  use  for 
it.  It  is  mandatory  to  receive  an  RCH  and  be  able  to  send  it  on  the  TP-RECOVER-RI  APDU. 
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A.6.  SUPPORT  OF  THE  SHARED  CONTROL  FUNCTIONAL  UNIT 
A.6.1 .  SHARED  CONTROL  FUNCTIONAL  UNIT  APDUS 

This  clause  does  not  apply  to  profiles  1 1 , 21  and  31 . 


Table  23  •  TP  APDUs  for  the  SHARED  Control  FU 


ITEM« 

PROTOCOL  DATA  UNITS 

ISO/IEC 
1002&4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-U-ERROR-RC 

M 

NA 

NA 

NA 

M 

M 

M 
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A.7.  SUPPORT  OF  THE  POLARIZED  CONTROL  FUNCTIONAL  UNIT 

This  clause  does  not  apply  to  profiles  12,  22  and  32.. 

A.7.1 .   POLARIZED  CONTROL  FUNCTIONAL  UNIT  APDUS 


Table  24  -  TP  APDUs  for  the  Polarized  Control  FU 


ITEM# 

PROTOCOL  DATA  UNITS 

ISO/lEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-GRANT-CONTROL-RI 

M 

M 

M 

M 

NA 

NA 

NA 

2 

TP-REQUEST-CONTROL-RI 

M 

M 

M 

M 

NA 

NA 

NA 
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A.8.  SUPPORT  OF  THE  HANDSHAKE  FUNCTIONAL  UNIT 

This  clause  applies  to  all  profiles. 

A.8.1 .   HANDSHAKE  FUNCTIONAL  UNIT  APDUS 


Table  25  -  TP  APDUs  for  the  Handshake  FU 


ITEM* 

PROTOCOL  DATA  UNITS 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-HANDSHAKE-RI 

M 

M 

M 

M 

C114 

0114 

0114 

2 

TP-HANDSHAKE-RC 

M 

M 

M 

M 

C114 

0114 

0114 

3 

TP-HANDSHAKE-AND-GRANT- 
CONTROL-RI 

c 

M 

M 

M 

NA 

NA 

NA 

1  ^ 

TP-HANDSHAKE-AND-GRANT- 
CONTROL-RC 

C 

M 

M 

NA 

NA 

NA 

114  If  the  Handshake  FU  is  implemented  (A.3.1/4)  then  M  else  NA 
A.8.2.  TP-HANDSHAKE-RI  APDU 

This  APDU  is  not  applicable  for  profiles  12,  22  and  32  when  the  handshake  FU  is  not 
implemented. 


Table  26  -  TP-HANDSHAKE-RI 


iTEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Confirmation-Urgency 

0 

11,21,31 

NA 

12,22,32 

M 
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A.8.3.  TP-HANDSHAKE-AND-GRANT-CONTROL-RI  APDU 

This  APDU  does  not  apply  to  profiles  12,  22  and  32. 

Table  27  -  TP-HANDSHAKE-AND-GRANT-CONTROL-RI 


ITEM* 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Confirmation-Urgency 

D 

11.21.31 

M 

A.9.  TP  PROTOCOL  -  SUPPORT  OF  THE  COMMIT  FUNCTIONAL  UNIT 

This  clause  applies  only  to  profiles  21 ,  22,  31  and  32. 
A.9.1 .  COMMIT  FUNCTIONAL  UNIT  APDUS 


Table  28  -  TP  APDUs  for  Commit  FU 


ITEM* 

PROTOCOL  DATA  UNITS 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-PREPARE-RI 

c 

NA 

C115 
/C116 

C115 
/C1 16 

NA 

C115 
/C1 16 

C115 
/C1 16 

2 

TP-DEFER-RI 

c 

NA 

C115 
/C1 16 

C115 
/C116 

NA 

C115 
/C1 16 

C115 
/C1 16 

3 

TP-HEURISTIC-REPORT-RI 

c 

NA 

C116 
/C115 

C1 16 
/C115 

NA 

C116 
/C115 

C116 
/C1 15 

4 

TP-TOKEN-GIVE-RI 

M 

NA 

M 

M 

NA 

M 

M 

1 15  If  the  implementation  is  capable  of  initiating  a  dialogue  (A.3.2.6/1)  then  M  else  NA 

1 16  If  the  implementation  is  capable  of  accepting  a  dialogue  (A.3.2.6/2)  then  M  else  NA 
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A.9.1 .1 .         TP-PREPARE-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  12. 

Table  29  -  TP-PREPARE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Data-Permitted 

0 

21,31 

M 

22,32 

NA 

A.9.2.  TP-DEFER-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  12. 

Table  30  -  TP-DEFER-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

ALLOWED 

NOTES 

1 

Type 

D 

22,32 

M 

End-Dialogue 

21.31 

M 

A.9.3.  TP-HEURISTIC-REPORT-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  12. 

Table  31  -  TP-HEURISTIC-REPORT-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Heuristic-RGport 

D 

M 

22 


Part  15  •  Transaction  Processing 
TP 


December  1992  (Stable) 
PDISP  12061-2 


A.9.4.  TP-TOKEN-GIVE-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  12. 


Table  32  -  TP-TOKEN-GIVE-RI 


rrEM« 

ISOIEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROnLE  ID 

STATUS 

T/LTV  ALLOWED 

NOTES 

1 

Reason 

D 

M 

Regular.  Keep 

2 

Correlator 

M 

M 
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A.10.    TP  PROTOCOL  -  SUPPORT  OF  THE  RECOVERY  FUNCTIONAL  UNIT 

This  clause  applies  only  to  profiles  21 ,  22,  31  and  32. 

A.10.1.  RECOVERY  FUNCTIONAL  UNIT  APDUS 


Table  33  -  TP  APDUs  for  Recovery  FU 


ITCH  M 

rnsj  1  uouL  u A 1 A  um  1 9 

10026-4 

ATD1 1 
A 1  rl  1 

ATP91 

M 1  1 

ATP19 

ATP99 

ATD^9 

Ti\J  1  CO 

1 

TP-BEGIN-DIALOGUE-RI 

M 

NA 

M 

M 

NA 

M 

M 

1 

2 

TP-BEGIN-DIALOGUE-RC 

M 

NA 

M 

M 

NA 

M 

M 

1 

3 

TP-BID-RI 

C 

NA 

M 

M 

NA 

M 

M 

1 

4 

TP-BID-RC 

C 

NA 

M 

M 

NA 

M 

M 

1.3 

5 

TP-RECOVER-RI 

M/C 

NA 

M 

/C1 17 

M 

/C1 17 

NA 

M 

/C117 

M 

/C117 

6 

TP-END-DIALOGUE-RI 

M 

NA 

M 

M 

NA 

M 

M 

7 

TP-TOKEN-PLEASE-RI 

C 

NA 

C118 

C118 

NA 

C118 

C118 

3 

8 

TP-INITIALIZE-RI 

M 

NA 

M 

M 

NA 

M 

M 

3 

9 

TP-INITIALIZE-RC 

M 

NA 

M 

M 

NA 

M 

M 

3 

10 

TP-TOKEN-GIVE-RI 

NA 

0 

O 

NA 

O 

0 

2 

117  If  the  recovery-context-handle  field  (A.5.7/4,  A.5.8/2)  is  supported  in  the  TP-INITIALIZE-RC 
and  TP-INITIALIZE-RI  APDUs  then  M  else  NA 

1 18  If  Two- Way  recovery  (A.3.2.9)  is  supported  then  M,  else  NA 
NOTES 

1  When  the  commitment  is  supported,  in  order  to  enable  channel  establishment  (initiator  or 
acceptor)  to  be  accepted,  it  is  required  to  be  able  to  support  both  the  bid  initiator  and  the  bid 
responder  roles. 

2  This  PDU  is  not  in  the  Recovery  FU  in  ISO/IEC  1 0026-4.  However  it  has  been  added  to  this 
ISP  as  required  for  support  of  Two-Way  recovery. 

3  This  APDU  is  specified  in  clause  A.5. 
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A.10.2.  TP-BEGIN-DIALOGUE-RI APDU 

A.10.2.1.       DETAIL  OF  THE  CHANNEL  FIELD  OF  TP-BEGIN-DIALOGUE- 
Rl  APDU 

This  table  does  not  apply  to  profiles  1 1  and  12. 


Table  34  -  TP-BEGIN-DIALOGUE-RI  (Recovery  FU) 


ITEM* 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Functional-Units 

D 

M 

{5} 

2 

Correlator 

M 

M 

0.2**31-1 

3 

Channel-Utilization 

D 

M 

one-way-recovery 

O 

two-way-recovery 

4 

Last-Partner-Identifier 

O/tA 

M 
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A.10.3.  TP-BEGIN-DIALOGUE-RC  APDU 

A.10.3.1.        DETAIL  OF  THE  CHANNEL  FIELD  OF  TP-BEGIN-DIALOGUE- 
RC  APDU 

This  table  does  not  apply  to  profiles  1 1  and  1 2. 


Table  35  -  TP-BEGIN-DIALOGUE-RC  (Recovery  FU) 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Result 

D 

M 

2 

Diagnostic 

M 

M 

3 

Correlator 

M 

M 

0.2**31-1 

A.10.4.  TP-END-DIALOGUE-RI  APDU 

This  table  does  not  apply  to  profiles  1 1  and  12. 

Table  36  -  TP-END-DIALOGUE-RI  (Recovery  FU) 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUy  ALLOWED 

NOTES 

1 

Confirmation 

D 

M 

False 

A.10.5.  TP-BID-RI  APDU 

This  table  does  not  apply  to  profiles  1 1  and  1 2. 

Table  37  -  TP-BID-RI  (Recovery  FU) 


ITEM« 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

CCR-Tokens-Requested 

M 

M 

2 

Last-Partner- Identifier 

0/M 

0..2**31-1 
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A.10.6.  TP-RECOVER-RI APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  12. 


Table  38  -  TP-RECOVER-RI  APDU 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VLN  ALLOWED 

NOTES 

1 

Reoovery-Context-Handle 

M 

M 

1..64  octets 

A.10.7.  TP-TOKEN-GIVE-R!  APDU 

Table  39  -  TP-TOKEN-GIVE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Reason 

D 

M 

Two-Way-recovery 

2 

Correlator 

C 

M 

NOTES 


This  table  is  not  in  ISO/IEC  10026-4.  However  it  has  been  added  to  this  ISP  as  required  for 
support  of  Two-Way  recovery. 


27 


Part  15  -  Transaction  Processing 
CCR 


December  1992  (Stable) 
PDISP  12061-3 


TITLE:  WORKING  DOCUMENT  FOR 

Information  Technology  -  Open  Systems  Interconnection  -  International  Standardized  Profile 
12061-3:  OSI  TP 

Part  3:  Support  of  the  CCR  Protocol. 

SOURCE:  Joint  AOW  /  EWOS  /  OIW  on  Transaction  Processing  . 
DATE:  December  18, 1992 

STATUS:  This  document  has  been  harmonized  among  the  three  workshops  (AOW/EWOS/OIW) 
and  has  been  submitted  to  SGFS  for  progression  to  ISP. 


i 


Part  1 5  -  Transaction  Processing 
CCR 


December  1992  (Stable) 
PDISP  12061-3 


CONTENTS 

INTRODUCTION 

1.  SCOPE 

2.  NORMATIVE  REFERENCES 

3.  DEFINITIONS  and  ABBREVIATIONS 

4.  NOTATION 

5.  SUPPORT  OF  OSI  CCR  PROTOCOL 

6.  CONFORMANCE 
ANNEX 

A.  SUPPORT  OF  THE  CCR  PROTOCOL  (NORMATIVE). 


Part  15  -  Transaction  Processing 
OCR 


December  1992  (Stable) 
PDISP  12061-3 


Introduction 


The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement 
outside  the  interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as 
transactions,  which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems 
Interconnection  (OSI)  a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by 
four  properties:  atomicity,  consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of 
messages,  but  that  the  exchanges  form  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified 
in  M-IT-02  and  TR  10000. 


Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 


Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles 
specified  in  Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the 
profiles  specified  in  Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session 
APDUs  for  each  of  the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard. 
These  six  parts  make  reference  to  Parts  2  to  4. 
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Part  15  -  Transaction  Processing 
OCR 

1.  SCOPE 

This  part  of  this  ISP  specifies  the  status  for  the  support  of  the  CCR  protocol  for  the  profiles 
Identified  in  Parti  of  this  ISP. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  applies. 

3.  DEFlNITiONS  AND  ABBREVIATEONS 

The  Definitions  and  Abbreviations  listed  in  Part  1  of  this  ISP  applies. 

4.  NOTATION 

The  notation  described  in  PART  1  of  this  SSP  Applies. 

5.  SUPPORT  OF  CCR  APDUs 

Annex  A  specifies  the  support  of  CCR  protocol. 

It  applies  to  profiles  21 ,  22, 31  and  32.  It  does  not  apply  to  profiles  1 1  and  12. 

6.  CONFORMANCE 

To  conform  to  the  OSI  CCR  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/EC  9805: 

•  All  mandatory  features  identified  in  Annex  A. 

•  All  selected  optional  features,  as  identified  in  the  completed  CCR  PICS. 
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ANNEX  A:  CCR  PDU  Supports  (Normative)  

Temporary  Editor's  Note:  This  curent  Annex  A  is  based  on  a  version  of  the  CCR  PICS  Profomna 
which  is  based  on  Version  1  of  the  CCR  protocol.  It  is  expected  that  the  CCR  PICS  Proforma  will 
be  aligned  to  Version  2.  This  part  of  the  OSI  TP  ISP  will  be  updated  accordinly  during  the  DISP 
ballot  period.  Would  the  CCR  PICS  Proforma  not  be  aligned  on  time,  the  necessary  material  will 
be  inserted  in  the  OSI  TP  ISP. 

A.1  DATE  OF  STATEMENT 

No  restrictions  applied  to  clause  A.1  of  ISO/I  EC  9805-2  by  this  ISP. 
A.2  IMPLEMENTATION  DETAILS 

No  restrictions  applied  to  clause  A.2  of  ISO/I  EC  9805-2  by  this  ISP. 
A.3  ISO/IEC  9805-1 

The  answer  shall  be  "Version  2". 

A.4  AMENDMENTS  IMPLEMENTED 


Table  1  -  AMENDMENTS  IMPLEMENTED 


1  ITEM* 

Amendment 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

ISO/IEC  9805-1  Amendment  1 

NA 

NA 

NA 

NA 

NA 

NA 

2 

ISO/IEC  9805-1  Amendment  2 

NA 

M 

M 

NA 

M 

M 

A.5  TECHNICAL  CORRIGENDA  IMPLEMENTED 

The  answer  shall  be  "None". 


At  the  time  of  approval  of  the  final  text  of  this  ISP  no  technical  corrigenda  was  approved  for 
ISO/IEC  9805.  When  this  condition  changes,  the  present  ISP  will  be  amended. 

A.6  GLOBAL  STATEMENT  OF  CONFORMANCE 
A.6.1  MANDATORY  FEATURES  IMPLEMENTED 

The  answer  shall  be  "Yes". 
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A.7  INITIATOR/RESPONDER  CAPABILITIES 

A.7.1  ATOMIC-ACTION-BRANCH  ESTABLISHMENT 


Table  2  -  ATOMIC-ACTION-BRANCH  ESTABLISHMENT  BY  PROFILE 


ITEM# 

Roles 

ISO/IEC 
9805-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

SUPERIOR 

0 

NA 

0101 

0101 

NA 

0101 

0101 

1 

2 

SUBORDINATE 

o 

NA 

C102 

0102 

NA 

0102 

0102 

1 

3 

MASTER 

o 

NA 

0103 

0103 

NA 

0103 

0103 

101  If  capable  of  acting  as  a  root  node  or  intermediate  node  then  M  else  I. 


102  If  capable  of  acting  as  a  leaf  node  or  intermediate  node  then  M  else  I. 

103  If  capable  of  acting  as  a  root  node  then  M  else  I. 
NOTES 

1 .  At  least  one  of  the  superior  or  subordinate  roles  must  be  implemented. 

A.7.2  SUPPORT  FOR  THE  CONCATENATION  MECHANISM 


Table  3  -  SUPPORT  FOR  THE  CONCATENATION  MECHANISM 


ITEM# 

Roles 

ISO/IEC 
9805-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

SENDER 

O 

NA 

O 

M 

NA 

O 

M 

2 

RECEIVER 

M 

NA 

M 

M 

NA 

M 

M 

Tempoary  note  The  detail  of  the  markings  for  row  1 ,  sender  role  may  require  further  study.  A 
draft  technical  corrigendum  to  ISO/IEC  9805:1990  adds  procedures  for  the  combined  use  of 
the  C-COMMIT  and  C-BEGIN  services,  and  the  C-ROLLBACK  and  C-BEGIN  services. 
Support  for  concatenation  for  these  combined  services  may  not  be  optional.  An  issue  is  that 
TP  makes  no  use  of  the  C-ROLLBACK  and  C-BEGIN  services.  This  issue  may  apply  to 
ISO/IEC  DIS  9805-2  (CCR  PICS  Proforma). 

A.7.3  OTHER  IMPLEMENTATION  CAPABILITIES 

No  restriction  is  applied  to  clause  A.7.3  of  ISO/IEC  9805-2  by  this  ISP. 
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A.8  CCR  PROTOCOL  -  GENERAL 

This  subclause  details  TP's  requirements  of  the  CCR  protocol.  The  protocol  tables  described 
below,  except  for  the  CCR  PDU  Usage  by  Profile,  do  not  apply  to  TP  profiles  1 1  and  1 2. 

A.9  CCR  PROTOCOL 
A.9.1  CCRPDUs 

This  table  specifies  the  support  level  of  each  PDU  with  respect  to  each  profile. 


Table  4  -  CCR  PDU  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISOAEC 
9805-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

C-BEGIN-RI 

C 

NA 

C104 
/C105 

C104 
/C105 

NA 

C104 
/C105 

C104 
/C105 

2 

C-BEGIN-RC 

O/C 

NA 

CI  05 
/C104 

C105 
/C104 

NA 

C105 
/C104 

C105 
/C104 

3 

C-PREPARE-RI 

O/C 

NA 

C104 
/C105 

C104 
/C105 

NA 

C104 
/C105 

C104 
/C105 

4 

C-READY-RI 

0 

NA 

C105 
/C104 

0105 
/C104 

NA 

C105 
/C104 

C105 
/C104 

5 

C-COMMIT-RI 

C 

NA 

C104 
/C105 

C104 
/C105 

NA 

C104 
/C105 

C104 
/C105 

6 

C-COMMIT-RC 

C 

NA 

C105 
/C104 

C105 
/C104 

NA 

C105 
/C104 

C105 
/C104 



7 



C-ROLLBACK-RI 

M 

NA 

M 

M 

NA 

M 

M 

8 

C-ROLLBACK-RC 

M 

NA 

M 

M 

NA 

M 

M 

9 

C-RECOVER-RI 

M 

NA 

M 

M 

NA 

M 

M 

10 

C-RECOVER-RC 

M 

NA 

M 

M 

NA 

M 

M 

104.  If  capable  of  acting  in  the  role  of  superior  then  M,  else  NA. 

105.  If  capable  of  acting  in  the  role  of  subordinate  then  M,  else  NA. 
A.9.2  C-BEGIN-RI 


Table  5  -  C-BEGIN-RI 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

ITEM« 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

injy/  ALLOWED 

NOTES 

1 

Atomic  Action  Identifier 

M 

M 

See  Table  6 

2 

Branchd-Suffix  -  Octet  String 

0/M 

0/M 

1  ..  64  octets 

1 

Branch-Suffix  -  integer 

0/M 

0/M 

0..2"3M 

1 

i  

User  Data 

0/M 

NA 

NOTES 
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1 .  At  least  one  of  these  forms  must  be  supported. 

9.2.1.      ATOMIC-ACTION  IDENTIFIER 

This  clause  provides  detail  at>out  the  Atomic-Action  Identifier  field  of  the  C-BEGIN  APDU. 


Table  6  -  ATOMIC-ACTION  IDENTIFIER  DETAIL 


Atomic-Action  Identifier  of  the 
C-BEGIN  APDU 

P 

ROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Master's  Name 
AE-Title-Form  1 
(Directory  name) 

C/M 

0/M 

1  ..  1024  octets 

1.2 

Master's  Name 
AE-TiUe-Form  2 
(Object  Id) 

C/M 

M 

1  ..  64  octets 

2 

Atomic  Action  Id.- 
Suffix  -  Octet  String 

C/M 

C106/M 

1  ..  64  octets 

2 

Atomic  Action  Id.- 
Suffix  -  Integer 

C/M 

C106/M 

0..2**31-1 

106  If  only  the  Master  role  is  supported  then  at  least  one  form  shall  be  supported,  otherwise  both 
forms  shall  be  supported. 

NOTES 

1 .  It  is  optional  to  be  able  to  generate  a  Master's  name  AE-TITLE-FORM-1  (RDM),  but  it  is 
mandatory  to  be  able  to  propogate  it  when  received  from  a  superior  by  an  intermediate  node 

2.  The  maximum  length  of  the  Atomic- Action  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Master's  Name  and 
suffix. 

A.9.3  C-BEGIN-RC 


Table  7  -  C-BEGIN-RC 


ISO/IEC  9805-2 

PROFILE 

ITEM« 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

User-data 

0/M 

NA 
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A.9.4  C-PREPARE-RI 

Table  8  -  C-PREPARE-Ri 


ISO/IEC  9805-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

User-data 

0/M 

M 

A.9.5  C-READY-RI 


Table  9  -  C-READY-RI 


ISO/IEC  9805-2 

PROFILE 

1  ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LyV  ALLOWED 

NOTES 

User-data 

O/M 

NA 

A.9.6  C-COMMIT-RI 

Table  10 -C-COMMIT-RI 


ISO/IEC  9805-2 

PROFILE 

1  ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

User-Data 

O/M 

M 

A.9.7  C-COMMIT-RC 

Table  11  -C-COMMIT-RC 

BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

1     ITEM*  1 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LyV  ALLOWED 

NOTES 

User-data 

O/M 

M 
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A.9.8  C-ROLLBACK-RI 

Table  12  -  C-ROLLBACK-RI 


ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

User-data 

0/M 

M 

A.9.9  C-ROLLBACK-RC 

Table  13  -  C-ROLLBACK-RC 


ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

User-data 

0/M 

M 

A.9.10  C-RECOVER-RI 

Table  14  -  C-RECOVER-RI 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

ITEM« 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Atomic  Action  Identifier 

M 

M 

See  Table  15 

2 

Branch  Identifier 

M 

M 

See  Table  16 

3 

Recovery  State 

M 

M 

See  Table  17 

4 

User  Data 

0/M 

M 
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A.9.10.1.  ATOMIC-ACTION  IDENTIFIER 

This  clause  provides  detail  about  the  Atomic-Action  Identifier  field  of  the  C-RECOVER  Rl  APDU. 


Table  15  •  ATOMIC-ACTION  IDENTIFIER  DETAIL 


Atomic-Action  identifier  of  tlie 
C-RECOVER-Ri  APDU 

PROFiL£  1 

ITEIM 

PARAiMETER 

STATUS 

PRORLE  ID 

STATUS 

T/iyV  ALLOWED 

NOTES 

1 

Master's  Name 
AE-Tide-Form  1 
(Directory  name) 

C 

0/M 

1  ..  1024  octets 

1 

Master's  Name 
AE-Title-Form  2 
(Ot){ect  Id) 

0 

M 

1  ..  64  octets 

1 

2 

Atomic  Action  td.- 
Suffix  -  Octet  String 

c 

M 

1  ..  64  octets 

1 

Atomic  Action  Id.- 
buffix  -  Integer 

0 

M 

0..2**31-1 

NOTES 

1 .  The  maximum  length  of  the  Atomic-Action  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Master's  Name  and 
suffix. 
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A.9.10.2.    BRANCH  IDENTIFIER 

This  clause  provides  detail  about  the  Branch  Identifier  field  of  the  C-RECOVER  Rl  APDU. 


Table  16  -  BRANCH  IDENTIFIER  DETAIL 


1 

Branch  Identifier  of  the 
C-RECOVER-RI  APDU 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Superior's- Name 
AE-Tiae-Form  1 
(Directory  name) 

c 

0/M 

1  ..  1024  octets 

1 

Superior's-Name 
AE-Title-Form  2 
(Obiect  Id) 

c 

M 

1 ..  64  octets 

2 

Branch"  Suffix  - 
Octet  string 

c 

M 

1 ..  64  octets 

Branch"  Suffix  - 
Integer 

c 

M 

0..2**31-1 

NOTES 

1 .  The  maximum  length  of  the  Branch  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Superior's  Name  and 
suffix. 
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A.9.10.3.  RECOVERY  STATE 

This  clause  provides  detail  about  the  RECOVERY-STATE  field  of  the  C-RECOVER  Rl  APDU. 

Table  17  -  RECOVERY-STATE 


Recovery-State  of  the 
C-RECOVER-RI  APDU 

PROFILE  1 

ITEM# 

STATE 

STATUS 

PROFILE  ID 

STATUS 

lILN  ALLOWED 

NOTES 

1 

Commit 

0 

C101/C102 

2 

Ready 

c 

0102/0101 

A.9.11  C-RECOVER-RC 

Table  18  -  C-RECOVER-RC 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

ITEM« 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA/  ALLOWED 

NOTES 

1 

Atomic  Action  Identifier 

M 

M 

SeeTab'e  19 

2 

Branch  Identifier 

M 

M 

See  Table  20 

3 

Recovery  State 

M 

M 

See  Table  21 

4 

User  Data 

0/M 

M 
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A.9.11.1.  ATOMfC-ACTION  IDENTIFIER 

This  clause  provides  detail  ^xxjt  the  Atomic-Action  Identifier  field  of  the  C-RECOVER  RC  APDU. 


Table  19  -  ATOMIC-ACTION  IDENTIFIER  DETAIL 


Atomlc-Aetion  Identifier  of  the 
C-RECOVER-RC  APDU 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PRORLE  to 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Master's  Name 
AE-Tltle-Form  1 
(Directory  name) 

0 

0/M 

1 ..  1024  octets 

1 

Master's  Name 
AE-Title-Form  2 
(Obiect  Id) 

c 

M 

1 ..  64  octets 

1 

2 

Atomic  Action  Id.- 
Suffix  •  Octet  String 

c 

M 

1 ..  64  octets 

1 

Atomic  Action  Id.- 
Suffix  -  Integer 

0 

U 

0 ..  2"31-1 

NOTES 

1 .  The  maximum  length  of  the  Atomic  Action  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Master's  Name  and 
suffix. 
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A.9.11.2.  BRANCH  IDENTIFIER 

This  clause  provides  detail  about  the  Branch  Identifier  field  of  the  C-RECOVER  RC  APDU. 


Table  20  -  BRANCH  IDENTIFIER  DETAIL 


1 

Branch  Identifier  of  the 
ORECOVER-RC  APDU 

PROFILE  1 

ITEM« 

PARAMETER 

STATUS 

PROHLE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Superior's- Name 
AE-Title-Form  1 
(Directory  name) 

c 

0/M 

1  ..  1024  octets 

1 

Superior's- Name 
AE-Title-Form  2 
(Object  Id) 

0 

M 

1  ..  64  octets 

1 

2 

Branch"  Suffix  - 
Octet  string 

C 

M 

1  ..  64  octets 

1 

Branch"  Suffix  - 
Integer 

0 

M 

0 ..  2"31-1 

NOTES 


1 .  The  maximum  length  of  the  Branch  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Superior's  Name  and 
suffix. 

A.9.11.3.  RECOVERY  STATE 

This  clause  provides  detail  about  the  RECOVERY-STATE  field  of  the  C-RECOVER  RC  APDU. 


Table  21  -  RECOVERY-STATE 


Recovery-State  of  the 
C-RECOVER-RC  APDU 

PROFILE 

ITEM# 

STATE 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Done 

C 

C102 
^CIOI 

2 

Unknown 

c 

C101 
/C102 

3 

Retry-later 

M 

M 
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INTRODUCTION 


The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement 
outside  the  Interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

0.      of  different  levels  of  complexity, 
d.     of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as 
transactions,  which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems 
Interconnection  (OSI)  a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by 
four  properties:  atomicity,  consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of 
messages,  but  that  the  exchanges  form  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified 
in  M-IT-02  and  TR  10000. 


Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 


Part  2  contains  the  specification  of  the  support  of  OS!  TP  APDUs  for  each  of  the  profiles 
specified  in  Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the 
profiles  specified  in  Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  Session  ,  Presentation  and 
ACSEAPDUs  for  each  of  the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard. 
These  six  parts  make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  - 
International  Standardized  Profile  12061-4:  OSI  Distributed 
Transaction  Processing. 

Part  4:  Support  of  SESSION,  PRESENTATION  AND  ACSE  PDUs 


1.  SCOPE 

This  part  of  this  ISP  specifies  the  status  for  the  support  of  the  Session,  Presentation  and  ACSE 
protocols  for  the  profiles  identified  in  Part  1  of  this  ISP. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  contained  in  Part  1  of  this  ISP  apply  to  this  part. 

4.  NOTATION 

The  notation  described  in  PART  1  of  this  ISP  Applies. 

5.  SUPPORT  OF  SESSION  SPDUs 

Annex  A  specifies  the  support  of  Session  protocol. 

6.  SUPPORT  OF  PRESENTATION  PPDUs 

Annex  B  specifies  the  support  of  Presentation  protocol. 

7.  SUPPORT  OF  ACSE  APDUs 

Annex  C  specifies  the  support  of  ACSE  protocol. 

8.  CONFORMANCE 

To  conform  to  the  OSI  ACSE  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  8650: 

•    All  mandatory  features  identified  in  Annex  C. 
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•  All  selected  optional  features,  as  identified  in  the  connpleted  ACSE  PICS. 

•  All  restrictions  as  specified  in  the  Common  Upper  Layer  Requirements 
ISP- ISO  11188-1. 

To  conform  to  the  OSI  Presentation  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  8823: 

•  All  mandatory  features  identified  in  Annex  B. 

•  All  selected  optional  features,  as  identified  in  the  completed  Presentation  PICS. 

•  All  restrictions  as  specified  in  the  Common  Upper  Layer  Requirements 
ISP  -  ISO  11188-1. 

To  conform  to  the  OSI  Session  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  8327: 

•  All  mandatory  features  identified  in  Annex  A. 

•  All  selected  optional  features,  as  identified  in  the  completed  Session  PICS. 

•  All  restrictions  as  specified  in  the  Common  Upper  Layer  Requirements 
ISP  -  ISO  11188-1. 
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ANNEX  A:  Session  PROTOCOL  PDUs  (Normative) 


This  subclause  details  TP's  requirements  on  the  Session  protocol.  The  reader  should  consult  the 
Upper  Layer  agreements  for  a  detailed  discussion  of  these  services.  This  ISP  only  specifies  PDU 
parameters  necessary  for  this  ISP. 

A.1  SUPPORTED  FUNCTIONS 


Table  1  -  SUPPORTED  FUNCTIONS 


BASE  STANDARD  ISO/IEC  8327-2 

PROFILE 

ITcM# 

CAPABIUTY 

ex  ATI  lO 

KriL/rlLb  lU 

t4\J  1  to 

1 

Kernel 

M 

M 

2 

Negotiated  Release 

0 

•(1) 

3 

Half  Duplex 

On 

NA 

3 

4 

Duplex 

On 

M 

5 

Expedited  Data 

0 

*(•) 

6 

Typed  Data 

0 

11,12 

*(l) 

21.22.31.32 

M 

7 

Capability  Data  Exchange 

c 

11,12 

21,22.31,32 

NA 

3 

8 

Minor  Synchronize 

0 

11,12 

21,22,31,32 

M 

9 

Symmetric  Synchronize 

0 

11,12 

21,22,31,32 

NA 

3 

10 

Major  Synchronize 

o 

'(') 

11 

Resyncronize 

o 

11,12 

21,22,31,32 

M 

12 

Exceptions 

0 

NA 

1,3 

13 

Activity  Management 

o 

11,12 

21,22,31,32 

NA 

2,3, 

14 

Data  Separation 

0 

11,12 

•(1) 

21,22,31,32 

M 

NOTES 


1.  Exceptions  FU  cannot  be  negotiated  because  Half  Duplex  is  not  allowed. 

2.  Activity  Management  FU  cannot  be  negotiated  for  these  profiles  because  the  Data 
Separation  FU  does  not  allow  the  Activity  Management  FU  to  also  be  selected. 

3.  Succesfully  accepting  these  functional  units  is  a  protocol  error.  If  any  of  the  following 
Functional  Units  is  proposed  on  a  CN  SRDU  the  Functional  Unit  shall  not  be  accepted  and 
the  corresponding  bit  shall  be  set  to  zero  on  the  Accept  SPDU. 
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A.2  ISO  8327  Protocol  Versions  Implemented 


Table  2  -ISO  8327  PROTOCOL  VERSIONS  IMPLEMENTED 


BASE  STANDARD  ISO/IEC  8327  -2 

PROFILE 

ITEM# 

CAPABIUTY 

STATUS 

PROFILE  ID 

STATUS 

NOTES 

1 

Version  1 

0 

2 

Version  2 

o 

M 

A.3  PROTOCOL  MECHANISMS 


Table  3-  PROTOCOL  MECHANISMS 


ISO/IEC  8327-2 

PROFILE 

ITEM« 

CAPABIUTY 

STATUS 

PROFILE  ID 

STATUS 

NOTES 

1 

Use  of  Transport  Expedited  Data 

0 

0 

2 

Reuse  of  Transport  Connection 

0 

3 

Basic  Concatenation 

M 

M 

4 

Extended  Concatenation 

0 

1 

5 

Seqmentation 

0 

"(1) 

6 

Segmentation  of  Unlimited  User  Data 

0 

•(1) 
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A.4  INITIATOR/RESPONDER  CAPABILITIES 


Table  4  -  INITIATOR/RESPONDER  CAPABILITIES 


ISO/IEC  8327-2 

PROFILE  1 

ITEM# 

CAPABIUTY 

STATUS 

PROFILE  ID 

STATUS 

NOTES 

i  1 

Initiator 

0 

C101 

Responder 

0 

M 

101 .  If  capable  of  initiating  an  Association  tlien  M,  else  I. 

A.5  SESSION  PROCEDURES  USAGE  BY  PROFILE 


This  table  specifies  the  supported  level  of  each  Session  PDU  with  respect  to  each  profile. 


Table  5  -  KERNEL  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM« 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Connect  (CN) 

c/c 

C103 
/M 

C103 
/M 

C103 
/M 

C103 
/M 

C103 
/M 

C103 
/M 

2 

Overflow  Accept(OA) 

c 

1 

1 

1 

1 

1 

1 

3 

Connect  Data  Overflow(CDO) 

c 

1 

1 

1 

1 

1 

1 

4 

Accept(AC) 

c/c 

C104 
/C103 

C104 
/C103 

C104 
/C103 

C104 
/C103 

C104 
/CI  03 

C104 
/CI  03 

5 

Refuse(RF) 

c/c 

M 

/C103 

M 

/C103 

M 

/C103 

M 

/CI  03 

M 

/C103 

M 

/C103 

6 

Finish(FN) 

0/C 

O/M 

O/M 

O/M 

O/M 

O/M 

O/M 
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Table  5  -  continued 


ITcM  # 

Protocol  D8I8  units 

ICO/IC^ 

Isu/ico 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

7 

Djsconnect(DN) 

O 

M 

/C105 

M 

/CI  05 

M 

/C105 

M 

/CI  05 

M 

/C105 

M 

/CI  05 

8 

Abort(AB) 

M 

M 

M 

M 

M 

M 

M 

9 

Abort  Accept(AA) 

O 

C106 

C106 

C106 

C106 

C106 

C106 

10 

Data  Transfer{DT) 

0/C 

M 

M 

M 

M 

M 

M 

11 

Prepare(PR) 

c/c 

C107 

C107 

C107 

C107 

0107 

C107 

103.  If  capable  of  initiating  an  Association  then  M,  else  I. 

104.  If  capable  of  responding  to  a  AARQ  APDU  then  M,  else  I. 


105.  If  capable  of  initiating  a  FINISH  then  M,  else  NA. 

106.  If  reusing  T-Connection  then  M,  else  I. 

107.  If  transport  expedited  available  then  M,  else  NA. 

Table  6  -  NEGOTIATED  RELEASE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Not  Finished(NF) 

O/M 

• 

2 

Give  Tokens(GT) 

0 

• 

1 

3 

Please  Tokens(PT) 

O/M 

* 

* 

* 

1 

NOTES 


1 .  These  PDUs  are  marked  *  in  this  table  because  the  Negotiated  Release  FU  is  marked  *  in 
Table  1 .  These  PDUs  may  be  used  else  where  in  different  ways. 
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Table  7  -  HALF  DUPLEX  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

1 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Give  Tokens(GT) 

O 

NA 

NA 

NA 

NA 

NA 

NA 

1 

2 

Please  Tokens(PT) 

O/M 

NA 

NA 

NA 

NA 

NA 

NA 

1 

NOTES 

1 .  These  PDUs  are  marke  NA  in  this  table  because  the  Half  Duplex  FU  is  marked  NA  in  Table 
1.  These  PDUs  may  be  used  else  where  in  different  ways. 

DUPLEX  FUNCTIONAL  UNIT  PROCEDURES 


No  additional  SPDUs  (this  clause  is  present  for  completeness). 

Table  8  -  EXPEDITED  DATA  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


1  ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

P 

11 

21 

31 

12 

22 

32 

Notes 

Expedited  Data(EX) 

O/M 

* 

i 
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Table  9  -  TYPED  DATA  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


1  ITEM# 

Protocol  Data  Units 

iSO/lEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

Typed  Data(TD) 

0/M 

M 

M 

* 

M 

M 

Table  10  -  CAPABILITY  DATA  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


1  ITEM« 

Protocol  Data  Units 

ISO/lEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Capability  Data(CD)) 

O/M 

* 

NA 

NA 

NA 

NA 

1 

2 

Capability  Data  Ack(CDA) 

M/C 

NA 

NA 

NA 

NA 

1 

NOTES 


1 .  Because  the  Capability  Data  FU  shall  never  be  selected  on  a  Session  Connection  for  Profiles 
21 ,  22,  31 ,  and  32,  the  Session  Protocol  Machine  will  generate  a  protocol  error  when  a  CD  or 
CDA  SPDU  is  received  in  these  profiles. 


Table  11  -MINOR  SYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


1  ITEM« 

Protocol  Data  Units 

ISO/lEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Minor  Sync  Point(MIP) 

O 

M 

M 

• 

M 

M 

2 

Minor  Sync  Point  Ack(MIA) 

o/c 

M 

M 

M 

M 

3 

Give  Tokens(GT) 

o 

M 

M 

M 

M 

4 

Please  Tokens(PT) 

O/M 

M 

M 

M 

M 
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Table  12  -SYMMETRIC  SYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY 

PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

[Minor  Sync  Point{MIP) 

0 

NA 

NA 

NA 

NA 

1 

2 

iMinor  Sync  Point  Ack(IVIIA) 

0/0 

NA 

NA 

• 

NA 

NA 

1 

NOTES 


1 .  Because  the  Symmetric  Synchronize  FU  shall  never  be  selected  on  a  Session  Connection  for 
Profiles  21 ,  22,  31 ,  and  32,  the  MIP  and  MIA  SPDUs  have  been  marked  NA.  They  may  be 
used  differently  elsewhere. 


Table  13  -MAJOR  SYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY 

PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Major  Sync  Point(MAP) 

0/M 

2 

Major  Sync  Point  Ack(MAA) 

M/C 

3 

Give  Tol<ens(GT) 

O 

1 

4 

Please  Tokens(PT) 

O/M 

1 

5 

Prepare(PR) 

0/0 

* 

1 

NOTES 


1 .  Because  the  Major  Synchronize  FU  has  been  marked  *  In  Table  1 ,  these  PDUs  have  been 
marked  *.  They  may  be  used  differently  elsewhere. 


Table  14  -RESYNCHRONtZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles  1 

11 

21 

31 

12 

22 

32 

Notes 

1 

RESYNCHRONIZE(RS) 

O/M 

M 

M 

M 

M 

1 

2 

RESYNCHRONIZE  Ack(RA) 

M/C 

M 

M 

M 

M 

1 

3 

Prepare(PRJ 

C/C 

0107 

0107 

• 

0107 

0107 

1 
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NOTES 

1 .  Because  the  ReSynchronize  FU  has  been  marked  in  Table  1  with  *  for  Profiles  1 1  and  1 2 
these  PDUs  have  been  marked  with  *  in  this  table.  They  may  be  used  differently  elsewhere. 


Table  15  -EXCEPTIONS  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Exception  Report(ER) 

O/M 

NA 

NA 

NA 

NA 

NA 

NA 

1 

2 

Exception  Data(ED) 

O/M 

NA 

NA 

NA 

NA 

NA 

NA 

1 

NOTES 

1 .  Because  the  ExceptionFU  shall  never  be  selected  for  a  Session  Connection,  the  Session 
Protocol  Machine  will  generate  a  protocol  error  when  an  ER  or  ED  SPDU  is  received. 

Table  16  -ACTIVITY  MANAGEMENT  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY 

PROFILE 


iTEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Activity  Start(AS) 

O/M 

NA 

NA 

NA 

NA 

2 

2 

Activity  Resume(AR) 

O/M 

NA 

NA 

NA 

NA 

2 

3 

Activity  Intefrupt(AI) 

O/M 

NA 

NA 

NA 

NA 

2 

4 

Activity  Interrupt  Ack(AIA) 

M/C 

NA 

NA 

NA 

NA 

2 

5 

Activity  Discard(AD) 

O/M 

NA 

NA 

NA 

NA 

2 

6 

Activity  Discard  Acl<(ADA) 

M/C 

NA 

NA 

NA 

NA 

2 

7 

Activity  End(AE) 

O/M 

NA 

NA 

NA 

NA 

2 

8 

Activity  End  Ack(AEA) 

M/C 

NA 

NA 

NA 

NA 

2 

9 

Prepare(PR) 

C/C 

NA 

NA 

NA 

NA 

2,3 

10 

Give  Tokens(GT) 

0 

NA 

NA 

NA 

NA 

2,3 

11 

Please  Tokens(PT) 

O/M 

NA 

NA 

NA 

NA 

2,3 

12 

Give  Tokens  Confirm(GTC) 

O/M 

NA 

NA 

NA 

NA 

1.2 

13 

Give  Tokens  Confirm  Ack(GTA) 

O/M 

NA 

NA 

NA 

NA 

1,2 

NOTES 


1 .  The  Give  tokens  confirm  and  Ack  are  a  result  of  the  control  give  service  and  require  the 
activity  management  FU. 

2.  Because  the  Activity  Management  FU  shall  never  be  selected  on  a  Session  connection  for 
profiles  21 ,  22,  31  and  32,  the  Session  Protocol  Machine  will  generate  a  protocol  error  when 
the  SPDU  is  received  in  these  Profiles. 

3.  Because  the  Activity  Management  FU  has  been  marked  in  Table  1  with  *  or  NA  the  PDUs 
have  been  marked  with  *  or  NA  in  this  table.  They  may  be  used  differently  elsewhere. 

t 
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A.6  SUPPORTED  PARAMETERS  OF  SESSION  PDUs. 
A.6.1  CONNECT  (CN)  SPDU 


Table  17  -  CONNECT  (CN)  SPDU 


ISO/IEC  8327-2 

PF 

lOFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUy  ALLOWED 

NOTES 

PGI  Connection  Identifier 

1 

PGI  default  (absent) 

0/M 

2 

PGI  default  (empty) 

0/M 

3 

Calling  SS-User  Reference 

0/M 

4 

Common  Reference 

O/M 

5 

Additional  Reference  Info 

0/M 

PGI  Connect/Accept  Item 

8 

PGI  default  (absent) 

0/M 

7 

PGI  default  (empty) 

O/M 

8 

PGI  default  (not  empty) 

0/M 

M 

9 

Protocol  Options 

C/M 

l/M 

10 

TSDU-Maximum-size 

O/M 

l/M 

11 

Version  Number 

O/M 

M 

Version  2 

12 

Initial  Serial  Number 

0/M 

11.12 

21.22.31.32 

M 

13 

Token  Setting  Item 

0/M 

11.12 

21.22.31.32 

M 

14 

Second  Initial  Serial  Number 

C/C 

11.12 

C108 

21.22.31.32 

1 

1 
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Table  17  -  continued 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

Single  Items 

15 

Session  User  Requirements 

0/M 

M 

16 

Calling  Session  Selector 

0/M 

M 

17 

Called  Session  Selector 

0/M 

M 

18 

PGI  "User  Data" 

0/M 

M 

19 

Data  Overflow 

C/C 

1 

I20 

PGI  "Extended  User  Data* 

C/C 

M 

108.     If  Symmetric-Sync  supported  then  O  else  I. 


NOTES 

1 .  Because  the  Symmetric  Synchronize  FU  shall  never  be  selected  for  a  Session  connection  for 
Profiles  21,  22,  31  and  32,  the  Session  Protocol  machine  will  ignore  the  Second  Initial  Serial 
Number  parameter  if  it  is  present  on  a  CN  SPDU  in  Profiles  21 ,  22,  31 ,  and  32. 


A.6.2  OVERFLOW  ACCEPT  (OA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP.  ! 
A.6.3  CONNECT  DATA  OVERFLOW  (CDO)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
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A.6.4  ACCEPT  (AC)  SPDU 


Table  18  -  ACCEPT(AC)  SPDU 


1 

ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUy  ALLOWED 

NOTES 

PGI  Connection  Identifier 

1 

PGI  default  (absent) 

0/M 

2 

PGI  default  (empty) 

0/IWl 

Calling  SS-User  Reference 

0/M 

4 

Common  Reference 

0/f^ 

e 

Additional  Reference  Info 

0/M 

PGI  Connect/Accept  Item 

ft 

PGI  default  (absent) 

0/M 

NA 

1 

7 

PGI  default  (empty) 

O/M 

NA 

1 

0 

9 

PGI  default  (not  empty) 

0/M 

M 

Q 

9 

Protocol  Options 

C/M 

1 

in 

TSDU-Maximum-size 

0/M 

l/M 

1 1 

Version  Number 

C/M 

M 

Version  2 

19 

Initial  Serial  Number 

0/M 

11,12 

21.22.31.32 

M 

13 

Token  Setting  Item 

0/M 

11.12 

21.22.31.32 

M 

14 

Second  Initial  Serial  Number 

C/C 

11,12 

C108 

21.22.31.32 

1 

2 

Single  Items 

15 

Token  Item 

O/M 

0/M 

16 

Session  User  Requirements 

0/M 

M 

17 

Calling  Session  Selector 

0/M 

M 

18 

Called  Session  Selector 

0/M 

M 

19 

PGI  "User  Data" 

0/M 

M 

20 

Enclosure  Item 

C 

13 
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Table  19  -  REFUSE  (RF)  SPDU 


ISOMEC  8327-2 

PF 

)OFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

PGI  default  (empty) 

0/M 

2 

PGI  default  (not  empty) 

0/M 

3 

Called  SS-User  Reference 

0/1^ 

4 

Common  Reference 

0/M 

5 

Additional  Reference  Info 

0/M 

Single  Items 

6 

Transport  Disconnect 

0/M 

0/M 

9 

Session  User  Requirements 

0/M 

M 

10 

Version  Number 

0/M 

M 

11 

Reason  Code 

0/M 

M 

12 

Enclosure  Item 

c 

A.6.6  FINISH  (FN)  SPDU 

Table  20  -  FINISH  (FN)  SPDU 

ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Transport  Disconnect 

0/M 

0/M 

2 

PGI  "User  Data" 

0/M 

M 

3 

Enclosure  Item 

c/c 

''        '  '     .  -  ■  '  I 

,  -  .      .  I 
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A.6.7  DISCONNECT  (DN)  SPDU 

Table  21  -  DISCONNECT  (DN)  SPDU 


ISO/IEC  8327-2 

PF 

iOFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

PGI  "User  Data" 

0/M 

M 

2 

Enclosure  Item 

c/c 

A.6.8  NOT  FINISHED  (NF)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.9  ABORT  (AB)  SPDU 

Table  22  -  ABORT  (AB)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Transport  Disconnect 

M 

M 

2 

Reflect  Parameter  Values 

0/M 

1 

3 

PGI  "User  Data" 

0/M 

M 

4 

Enclosure  Item 

c/c 

A.6.10  ABORT  ACCEPT  (AA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.11  DATA  TRANSFER  (DT)  SPDU 

Table  23  -  DATA  TRANSFER  (DT)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LW  ALLOWED 

NOTES 

1 

User  Information  Field 

0/M 

M 

2 

Enclosure  Item 

C/c 

A.6.12  EXPEDITED  DATA  (EX)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
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A.6.13  TYPED  DATA  (TD)  SPDU 


Table  24  .  TYPED  DATA  (TD)  SPDU 


1                  1                       iSO/lEC  8327-2 

Pf 

tOFILE 

ITEM* 

1  PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

HEndosure  Item 

0/0 

• 

I2                fluser  Information  Field 

0/M 

M 

A.6.14  CAPABILITY  DATA  (CD)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.15  CAPABILITY  DATA  ACK  (CDA)  SPDU 


This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 
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A.6.16  GIVE  TOKENS  (GT)  SPDU 


This  PDU  is  not  used  by  Profiles  1 1  and  12. 

Table  25  •  GIVE  TOKENS  (GT)  SPDU 


ISO/IEC  8327-2 

PROFILE  1 

1  ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES  1 

1 

Token  Item 

0/M 

M 

Minor  Sync 

Other  Tokens 

2 

PGI  'User  Data* 

C/C 

M 

3               lEndosure  Item 

C/C 

A.6.17  PLEASE  TOKENS  (PT)  SPDU 


This  PDU  is  not  used  by  Profiles  1 1  and  12. 

Table  26  -  PLEASE  TOKENS  (PT)  SPDU 


1 

ISO/IEC  8327-2 

PROFILE 

1  ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

Token  Item 

0/M 

M 

Minor  Sync 

NOTES  1 

Other  Tokens 

PGI  "User  Data- 

0/M 

M 

Enclosure  Item 

C/C 

December  1992  (Stable) 
PDISP  12061-4 
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A.6.18  MINOR  SYNC  POINT  (MIP)  SPDU 

This  PDU  is  not  used  by  Profiles  1 1  and  12. 

Table  27  -  MINOR  SYNC  POINT  (MIP)  SPDU 


ISO/lEC  8327-2 

PF 

tOFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LyV  ALLOWED 

NOTES 

Sync  Type  Item 

0/M 

M 

Serial  Numtier 

M 

M 

• 

PGI  "User  Data" 

0/M 

M 

Enclosure  Item 

0 

M 

A.6.19  MINOR  SYNC  POINT  ACK  (MIA)  SPDU 

This  PDU  is  not  used  by  Profiles  1 1  and  1 2. 

Table  28  -  MINOR  SYNC  POINT  ACK  (MIA)  SPDU 


ISO/lEC  8327-2 

PROFILE 

r  ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

Serial  Number 

M 

M 

r 

PGI  "User  Data" 

0/M 

M 

Enclosure  Item 

c/c 

A.6.20  MAJOR  SYNC  POINT  (MAP)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 


A.6.21  MAJOR  SYNC  POINT  ACK  (MAA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.22  RESYNCHRONIZE  (RS)  SPDU 

This  PDU  is  not  used  by  TP  for  profiles  1 1  and  1 2. 
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Table  29  -  RESYNCHRONIZE  (RS)  SPDU 


ISO/IEC  8327-2 


PROFILE 


ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

Enclosure  Item 

0 

^oken  Setting  Item 

0/M 

M 

Minor  Sync 

Other  Tokens 

3 

Resvnc  Type 

0/M 

M 

4 

Serial  Number 

0/M 

M 

5 

Second  Resync  Type 

0 

1 

6 

Second  Serial  Number 

0 

1 

7 

PGI  "User  Data" 

0/M 

M 

A.6.23  RESYNCHRONIZE  ACK  (RA)  SPDU 


Table  30  RESYNCHRONIZE  ACK  (RA)  SPDU 


This  PDU  is  not  used  by  TP  for  profiles  1 1  and  1 2. 


ISO/iEC  8327-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

Enclosure  Item 

C 

Token  Setting  Item 

0/M 

32 

M 

Minor  Sync 

• 

Other  Tokens 

3 

Resync  Type 

0/M 

1 

4 

Serial  Number 

0/M 

M 

5 

Second  Resync  Type 

C/C 

1 

6 

Second  Initial  Serial  Number 

0/0 

1 

7 

PGI  "User  Data" 

0/M 

M 
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A.6.24  PREPARE  (PR)  SPDU 

Table  31  •  PREPARE  (PR)  SPDU 
This  PDU  is  not  used  by  TP  for  profiles  1 1  and  12. 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID  STATUS 

T/UV  ALLOWED 

NOTES 

1 

Prepare  Type 

M 

M 

2 

Resync  Type 

C 

 1  

3 

Second  Resync  Type 

C 

A.6.25  EXCEPTION  REPORT  (ER)  SPDU 


This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  prohibited 
A.6.26  EXCEPTION  DATA  (ED)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  prohibited 
A.6.27  GIVE  TOKENS  CONFIRM  (GTC)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.28  GIVE  TOKENS  CONFIRM  ACK  (GTA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  11  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.29  ACTIVITY  START  (AS)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.30  ACTIVITY  RESUME  (AR)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 


December  1992  (Stable) 
PDISP  12061-4 


20 


Part  15  -  Transaction  Processing 
Session   


December  1992  (Stable) 
PDISP  12061-4 


A.6.31  ACTIVITY  INTERRUPT  (Al)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 .22.31  and  32  is  prohibited 

A.6.32  ACTIVITY  INTERRUPT  ACK  (AIA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21.22,31  and  32  is  prohibited 

A.6.33  ACTIVITY  DISCARD  (AD)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 .22,31  and  32  is  prohibited 

A.6.34  ACTIVITY  DISCARD  ACK  (ADA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.35  ACTIVITY  END  (AE)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 .22,31  and  32  is  prohibited 

A.6.36  ACTIVITY  END  ACK  (AEA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 .22.31  and  32  is  prohibited 
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ANNEX  B:  Presentation  PROTOCOL  PDUs  (Normative) 


B.I .  PRESENTATION  SERVICE  PARAMETERS 

This  subclause  details  TP's  requirements  on  the  presentation  protocol.  The  reader  should 
consult  the  Upper  Layer  agreements  for  a  detailed  discussion  of  these  services.  This  ISP  only 
specifies  PDU  parameters  necessary  for  this  ISP. 

B.I  .2.  CONNECTION  INITIATOR  or  RESPONDER  CAPABILITIES 


Table  1  -  CONNECTION  INITIATOR  OR  RESPONDER  CAPABILITIES 


ISO/lEC  8823-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  10 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Initiator 

0 

0101 

2 

Respond er 

0 

M 

101 .     If  capable  of  initiating  an  association  then  M,  else  I. 
B.I  .3.  PROTOCOL  MECHANISMS 

Table  2  -PROTOCOL  MECHANISMS 


ISO/IEC  8823-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

p(.410  (1984) 

0 

NA 

1 

2 

INormal 

0 

M 

J 

I 
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NOTES 

1 .  Implementations  that  support  X.410  mode  shall  respond  to  a  CP  PPDU  proposing  X.41 0- 
1984  nrK3de  with  an  S-U-ABRT;  where  the  user  data  contains  an  Abortlnformation  data 
element  (defined  in  X.410),  which  contains  an  AbortReason  (type  INTEGER)  of  value  4 
(protocol  error).  Implementations  that  do  not  support  X.41 0-1 984  mode  shall  respond  with 
either  a  Presentation-Provider  abort  or  a  Presentation-Provider  Reject. 

B.I .4.  FUNCTIONAL  UNITS 


Table  3  -  FUNCTIONAL  UNITS 


ISO/IEC  8823-2 

PROFILE  1 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUy  ALLOWED 

NOTES 

1 

Kernel 

M 

M 

2 

Presentation  Context  Management 

0 

3 

Presentation  Context  Restoration 

c 

B.I .5.  PRESENTATION  PDU  USAGE  BY  PROFILE 


Table  4  KERNEL  PDU  USAGE  BY  PROFILE 


iTEM# 

PROTOCOL  DATA  UNITS 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

CONNECT 

PRESENTATION  (CP) 

c/c 

C101 

/M 

C101 
/M 

C101 
/M 

C101 
/M 

C101 
/M 

C101 
/M 

2 

CONNECT 

PRESENTATION  ACCEPT 
(CPA) 

c/c 

C102 
/C101 

C102 
/C101 

C102 
/C101 

C102 
/C101 

C102 
/C101 

C102 
/C101 

3 

CONNECT 

PRESENTATION  REJECT 
(CPR) 

c/c 

M 

/C101 

M 

/C101 

M 

/C101 

M 

/C101 

M 

/C101 

M 

/C101 

4 

ABNORMAL  RELEASE 
PROVIDER  (ARP) 

M 

M 

M 

M 

M 

M 

M 

5 

ABNORMAL  RELEASE 
USER  (ARU) 

M 

M 

M 

M 

M 

M 

M 

1  6 

PRESENTATION  DATA 
i  (TD) 

M 

M 

M 

M 

M 

M 

M 

102.     If  capable  of  accepting  an  AARQ  APDU  then  M,  else  NA. 
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B.1.6.  PRESENTATION  CONTEXT  MANAGEMENT  PDU  USAGE  BY 
PROFILE 


Table  5  PRESENTATION  CONTEXT  MANAGEMENT  PDU  USAGE  BY  PROFILE 


iTEM# 

PROTOCOL  DATA  UNITS 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

ALTER  CONTEXT  (AC) 

O/M 

* 

2 

ALTER  CONTEXT  ACKNOWLEDGE 
(ACA) 

M 

* 

• 

* 

8.1 .7.  OTHER  PRESENTATION  PDU  USAGE  BY  PROFILE 


Table  6  OTHER  PRESENTATION  PDU  USAGE  BY  PROFILE 


ITEM# 

PROTOCOL  DATA  UNITS 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

PRESENTATION  TYPED  DATA 
(TTD) 

M 

M 

M 

• 

M 

M 

2 

EXPEDITED  DATA  (TE) 

O/M 

* 

• 

3 

CAPABILITY  DATA  (TC) 

O/M 

NA 

NA 

NA 

NA 

4 

CAPABILITY  DATA 
ACKNOWLEDGE  (TCC) 

O/M 

NA 

NA 

NA 

NA 

5 

RESYNCHRONIZE  (RS) 

O/M 

• 

M 

M 

M 

M 

6 

RESYNCHRONIZE 
ACKNOWLEDGE  (RSA) 

O/M 

M 

M 

M 

M 

B.I .8.  PRESENTATION  CONTEXT  RESTORATION  FUNCTIONAL  UNIT 


No  additional  PPDUs. 
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B.2.  SUPPORTED  PARAMETERS 

B.2.1.  CONNECT  PRESENTATION  (CP)  PPDU 


Table  7  -  CONNECT  PRESENTATION  (CP)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Callinq  Presentation  Selector 

0/M 

M 

2 

Called  Presentation  Selector 

0/M 

M 

3 

Mode  Selector 

M 

M 

Normal 

4 

Presentation  Context  Definition  List 

0/M 

M 

5 

Default  Context  Name 

0/M 

C103 

6 

Protocol  Version 

0/M 

M 

7 

Presentation  Requirements 

0/M 

1 

B 

User  Session  Requirements 

0/M 

C104 

1 

9 

User  Data 

0/M 

M 

103.  If  the  Expedited  Data  FU  is  supported  then  M,  else  I. 

104.  If  the  Context  Management  FU  is  supported  then  M,  else  I. 
NOTES 

1 .  TP  does  not  use  this  parameter,  however  a  U-ASE  is  not  prohibited  from  using  it,  subject  to 
the  restrictions  imposed  by  TP  on  the  use  of  Session  Functional  Units. 

B.2.2.  CONNECT  PRESENTATION  ACCEPT  (CPA)  PPDU 


Table  8  -  CONNECT  PRESENTATION  ACCEPT  (CPA)  PPDU 


ISO/lEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUW  ALLOWED 

NOTES 

1 

Respondinq  Presentation  Selector 

0/M 

M 

2 

Mode  Selector 

M 

M 

Normal 

3 

Presentation  Context  Definition  Result 
Ust 

0/M 

M 

4 

Protocol  Version 

0/M 

M 

5 

Presentation  Requirements 

0/M 

1 

6 

User  Session  Requirements 

0/M 

C104 

1 

7 

User  Data 

0/M 

M 

NOTES 


1 .  TP  does  not  use  this  parameter,  however  a  U-ASE  is  not  prohibited  from  using  it,  subject  to 
restrictions  imposed  by  TP  on  the  use  of  Sesison  Functional  Units. 
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B.2.3.  CONNECT  PRESENTATION  REJECT  (CPR)  PPDU 
Table  9  -  CONNECT  PRESENTATION  REJECT  (CPR)  PPDU 


ISO/IEC  8823-2 

P 

ROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Responding  Presentation  Selector 

0/M 

M 

2 

Presentation  Context  Definition  Result 
List 

0/M 

M 

3 

Protocol  Version 

O/M 

M 

4 

Default  Context  Result 

0/M 

C105 

5 

Provider  Reason 

0/M 

M 

1 

6 

User  Data 

0/M 

M 

105.     If  capable  of  proposing  Default  Context  then  M,  else  I. 


NOTES 

1 .   For  enhanced  interoperability  it  is  recommended  that  appropriate  provider  reason  values  be 
sent  with  all  CPR  PPDUs. 

B.2.4.  ABNORMAL  RELEASE  USER  (ARU)  PPDU 

Table  10  -  ABNORMAL  RELEASE  USER  (ARU)  PPDU 


ISO/IEC  8823-2 

PROFILE 

iTEiyi# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUW  ALLOWED 

NOTES 

1 

Presentation  Context  Identifier  List 

0/M 

M 

2 

User  Data 

0/M 

M 

B.2.5.  ABNORMAL  RELEASE  PROVIDER  (ARP)  PPDU 

Table  11  -  ABNORMAL  RELEASE  PROVIDER  (ARP)  PPDU 


ISO/lEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Abort  Reason 

O/M 

M 

1 

2 

Event  Identifier 

O/M 

M 

2 

NOTES 

1 .   For  enhanced  interoperability  it  is  recommended  that  appropriate  provider  reason  values  be 
sent  with  all  ARP  PPDUs. 
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2.  For  enhanced  interoperability  it  is  recommended  that  appropriate  event  identifier  values  be 
sent  with  all  ARP  PPDUs. 

B.2.6.  ALTER  CONTEXT  (AC)  PPDU 

This  PPDU  Is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
B.2.7.  ALTER  CONTEXT  ACKNOWLEDGE  (ACA)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
B.2.8.  PRESENTATION  DATA  (TD)  PPDU 


Table  12  •  PRESENTATION  DATA  (TD)  PPDU 


1— 

ISO/IEC  8S23-2 

PROFILE 

1  ITERM 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

|l  Huser-data 

0/M 

M 

B.2.9.  PRESENTATION  TYPED  DATA  (TTD)  PPDU 

Table  13  -  PRESENTATION  TYPED  DATA  (TTD)  PPDU 

This  PPDU  is  not  applicable  to  profiles  1 1  and  1 2. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

User-data 

0/M 

M 

B.2.10.         EXPEDITED  DATA  (TE)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
B.2.1 1 .        CAPABILITY  DATA  (TC)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP.  It  can  be  used  by 
Profiles  1 1  and  12  However  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited. 

B.2.12.        CAPABILITY  DATA  ACKNOWLEDGE  (TCC)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP.  It  can  be  used  by 
Profiles  1 1  and  12  However  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited. 
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B.2.13.         RESYNCHRONIZE  (RS)  PPDU 

Table  14-  RESYNCHRONIZE  (RS)  PPDU 

This  PPDU  is  not  applicable  to  profiles  11  and  12. 


BASE  STANDARD  ISO  8823 

P 

ROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Presentation  Context  Identifier  List 

c/c 

0104 

2 

User-data 

O/M 

M 

B.2.14.         RESYNCHRONIZE  ACKNOWLEDGE  (RSA)  PPDU 
Table  15  -  RESYNCHRONIZE  ACKNOWLEDGE  (RSA)  PPDU 

lis  PPDU  is  not  applicable  to  profiles  1 1  and  12. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUV  ALLOWED 

NOTE 

1 

Presentation  Context  Identifier  List 

O/M 

C104 

2 

User-data 

O/M 

M 
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B.2.15.        SESSION  SERVICE  PRIMITIVES  NOT  CARRYING 
PRESENTATION  PCI 


Table  16  SESSION  SERVICE  PRIMITIVES  NOT  CARRYING  PRESENTATION  PCI 


1 

1  ITEM* 

1 

PRIMITIVES 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

S-REL  req/ind 

C 

O/M 

O/M 

O/M 

O/M 

O/M 

O/M 

2 

S-REL  rsp/cnf 

C 

*(M) 
/CI  06 

•(M) 
/C106 

*(M) 
/C106 

*(M) 
/C106 

*(M) 
/C106 

•(M) 
/C106 

— 

S-PT  req/ind 

0 

M 

M 

M 

M 

4 

S-SYNm  req/ind 

0 

M 

M 

M 

M 

5 

S-SYNm  rsp/cnf 

0 

M 

M 

M 

M 

6 

S-SYNM  req/ind 

c 

* 

• 

7 

S-SYNM  rsp/cnf 

O/M 

• 

• 

• 

• 

8 

S-UER  req/ind 

0 

NA 

NA 

NA 

NA 

NA 

NA 

9 

S-ACTS  req/ind 

0 

NA 

NA 

NA 

NA 

10 

S-ACTR  req/ind 

0 

NA 

NA 

NA 

NA 

11 

S-ACTE  req/ind 

0 

NA 

NA 

NA 

NA 

12 

S-ACTE  rsp/cnf 

0 

NA 

NA 

NA 

NA 

106.     If  capable  of  initiating  an  S-REL  req  M  then  else  I. 
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B.3.  SUPPORT  OF  SYNTAXES 


B.3.1.  TRANSFER  SYNTAXES  SUPPORTED 


Table  17  -  TRANSFER  SYNTAXES  SUPPORTED 


1                                                                                       1  SUPPORT 

iTEM# 

TYPE 

DETAIL 

BASE 

P 

bbiect  Identifier 

ioint-iso-cdtt  asn1(1)  basic-encodinq(l) 

M 

IVI  1 

B.3.2.  ABSTRACT  SYNTAXES  SUPPORTED 


Table  18  -  ABSTRACT  SYNTAXES 


SUPPORT 

NOTES  1 

ITEHI# 

TYPE 

DETAIL 

PROFILE  ID 

BASE 

p 

: 

Object  Identifier 

ioint-iso-cdtt  association-control(2)  abstract- 
syntax(  1 )  apdus(O)  version  1(1) 

0 

M 

Object  Identifier 

joint-iso-ccitt  ccr(7)  abstract-syntax(l)  apdus(O) 

11.12 

o 

1 

ver5ion2(2) 

21,22.31,32 

0 

M 

3 

Object  Identifier 

joint-iso-cdtt  tp(10)  ab)stract-syntax(l)  apdus(O) 
version1(1) 

0 

M 

NOTES 


1 .  This  ISP  specifies  that  a  referencing  specification  shall  not  use  CCR  when  operating  w'rth 
profile  1 1  or  profile  1 2  (in  particular,  refer  to  Parts  5  and  6  clause  7).  However,  when  the 
abstract  syntaxes  are  negotiated  at  the  Presentation  level,  it  is  not  possible  to  identify 
whether  a  protocol  error  shall  be  detected  or  not  (this  can  be  detected  at  the  081  TP  level). 
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ANNEX  C:  ACSE  PROTOCOL  PDUs  (Normative) 


This  subclause  details  TP's  use  of  ACSE  services  and  parameters.  The  reader  should  consult  the  upper 
layer  agreements  for  a  detailed  discussion  of  these  services.  This  ISP  only  specifies  PDU  parameters 
necessary  for  this  ISP. 

C.1 .    SUPPORTED  FUNCTIONS 


Table  1  -  SUPPORTED  FUNCTIONS 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Normal  Mode 

O 

M 

2 

X.410-  1984  mode 

0 

NA 

1 

3 

Rules  for  Extensibility 

M 

M 

4 

Supports  Operation  of  Session  Vers.  2 

O 

1^ 

NOTES 

1 .   Implementations  that  support  X.410  mode  shall  respond  to  a  CP  PPDU  proposing  X.41 0-1984  mode 
with  an  S-U-ABRT;  where  the  user  data  contains  an  Abortlnformation  data  element  (defined  in 
X.410),  which  contains  an  AbortReason  (type  INTEGER)  of  value  4  (protocol  error).  Implementations 
that  do  not  support  X.41 0-1984  mode  shall  respond  with  either  a  Presentation-Provider  abort  or  a 
Presentation-Provider  Reject. 

C.2.    INITIATOR/RESPONDER  CAPABILITIES 


Table  2  -INITIATOR/RESPONDER  CAPABILITIES 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Association  Initiator 

O 

11,12 

0 

21,22,31,32 

M 

2 

Association  Responder 

0 

11,12 

M 

1 

21,22,31.32 

M 

NOTES 


1 .  An  implementation  shall  be  capable  of  rejecting  an  AARQ  APDU,  acceptance  of  an  AARQ  APDU  is 
optional. 
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C.3.    FUNCTIONAL  UNITS 


TabSe  3  -FUNCTIONAL  UNITS 


1 

ISO/IEC  8650-2 

P 

ROFILE  1 

ITEM« 

PARAMETER 

STA 

TUS 

PROFILE  ID 

STATUS 

T/LyV  ALLOWED 

NOTES 

1 

Kernel 

M 

M 

2 

Authentication 

0 

C.4.    ACSE  PDU  USAGE  BY  PROFILE 


Table  4  ACSE  PDU  USAGE  BY  PROFILE 


1  ITEM# 

Protocol  Data  Units 

ISO/IEC 

86S9-2 

Profiles 

11 

21 

31 

12 

22 

.„  1 

32 

Notes 

1 

A-ASSOCIATE-REQUEST 
(AARQ) 

0/0 

0101/M 

M 

M 

0101/M 

M 

M 

1 

A-ASSOCIATE-RESPONSE 
(AARE) 

0/0 

M/0101 

M 

M 

M/0101 

M 

M 

1 

A-RELEASE-REQUEST 
(RLRQ) 

O/M 

O/M 

0/1^ 

O/M 

O/M 

O/M 

O/M 

4 

A-RELEASE-RESPONSE 
(RLRE) 

M/C 

M/0102 

M/0102 

M/0102 

M/0102 

M/0102 

M/0102 

5 

A-ABORT  (ABRT) 

0/0 

M 

M            1  M 

M 

M 

M 

101.     If  capable  of  initiating  an  Association  then  M,  else  I. 


102.     If  capable  of  initiating  A-RELEASE  then  M,  else  I. 
NOTES 

1 .  All  implementations,  including  initiator  only  ones,  shall  have  the  capability  to  receive  an  AARQ  APOU 
and  rejecting  it  with  an  AARE  APDU. 
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C.5.    A-ASSOCIATE-REQUEST  (AARQ) 


Table  5  -  A-ASSOCIATE-REQUEST  (AARQ) 


1  

j 

ISOAEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

C/M 

M 

2 

Application  Contoxt  Namo 

M 

M 

3 

Calling  AP  Title 

0/M 

11.12 

O/M 

See  Table  10 

1 

21,31,22,32 

M 

See  Table  10 

1 

4 

0/M 

1 1,12 

0/M 

See  Table  1 0See  Table 

1 

91  11  99  19 

M 

IVl 

10 

1 

5 

— '■  ' — ; — z  

Calling  AP  Invocation  Identifier 

U/M 

11  19 
11,1^ 

L//M 

1 

21,31,22,32 

0/M 

1,  2 

g 

Tallin/1  At^   lou/v^sition  IHonfifior 
\./clllliiy  nC  iiivviwduuii  ludiuiid 

0/M 

1112 

0/M 

1 

21,31,22.32 

0/M 

1.2 

7 

Called  AP  Title 

0/M 

0/M 

See  Table  10 

8 

Called  AE  Qualifier 

0/M 

0/M 

See  Table  10 

9 

Called  AP  Invocation  Identifier 

0/M 

11,12 

0/M 

1.3 

21,31,22,32 

0/M 

1.3 

10 

Called  AE  Invocation  Identifier 

0/M 

11,12 

0/MO/M 

1.3 

21,31,22.32 

1.3 

11 

Implementattion  Information 

C/M 

1 

12 

Requester  ACSE  Requirements 

C/M 

13 

Mechanism  Name 

C/M 

* 

14 

Calling  Autfientication  Value 

C/M 

lis 

User  Information 

0/M 

M 

NOTES 


1 .  For  implementations  using  association  pools,  these  parameters  are  recommended  in  order  to  re-use 
associations. 

2.  If  this  parameter  is  received,  then  it  is  recommended  to  be  logged  and  used  for  the  reestablishment 
of  the  association  during  transaction  recovery. 

3.  If  this  parameter  is  sent,  then  it  is  recommended  to  be  logged  and  used  for  the  reestablishment  of  the 
association  during  transaction  recovery. 
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C.6.    A-ASSOCIATE-RESPONSE  (AARE) 


Table  6  -  A-ASSOCIATE-RESPONSE  (AARE) 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Protocol  Version 

C/M 

M 

2 

Application  Context  Name 

M 

M 

3 

Responding  AP  Title 

0/M 

11,12 

0/M 

See  Table  10 

1 

21,31,22,32 

M 

See  Table  10 

1 

4 

Responding  AE  Qualifier 

0/M 

11,12 

0/M 

See  Table  10 

1 

?1  "^l  ??  "1? 

IVI 

1 

5 

Responding  AP  Invocation  Identifier 

0/M 

11,12 

0/M 

21,31,22,32 

0/M 

2 

6 

Responding  AE  Invocation  Identifier 

0/M 

11,12 

0/M 

21,31,22,32 

0/M 

2 

7 

Result 

M 

M 

8 

Result  Source  -  Diagnostic 

M 

M 

1-10 

C 

11  - 14 

9 

Implementation  Information 

O/M 

10 

Requester  ACSE  Requirements 

C/M 

11 

Mechanism  Name 

C/M 

12 

Calling  Authentication  Value 

C/M 

13 

User  Information 

0/M 

M 

NOTES 


1 .  This  parameter  shall  be  present  on  an  AARE  APDU  if  the  called  parameter  was  present  in  the  AARQ 
APDU  and  the  responding  parameter  is  different  from  the  called  parameter. 

2.  If  this  parameter  is  received,  then  it  is  recommended  to  be  logged  and  used  for  re-establishment  of 
the  association  during  transaction  recovery. 


C.7     A-RELEASE-REQUEST  (RLRQ) 


Table  7  -  A-RELEASE-REQUEST  (RLRQ) 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

J/Uy  ALLOWED 

NOTES 

1 

Reason 

0/M 

1 

2 

User  information 

O/M 

1 
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C.8.    A-RELEASE-RESPONSE  (RLRE) 

Table  8  -  A-RELEASE-RESPONSE  (RLRE) 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Reason 

0/M 

1 

2 

lUser  information 

0/M 

1 

C.9.    A-ABORT  (ABRT) 

Table  9  -  A-ABORT  (ABRT) 


ISO/IEC  8650-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Abort  Source 

M 

M 

2 

At)ort  Diagnostic 

0 

3 

User  Information 

0/M 

M 

C.10.  AE  TITLE  NAME  FORMS 

Table  10  -  AE  TITLE  MAME  FORMS 


ISO/IEC  8650-2 

PROFILE 

ITEM* 

SYNTAX  FORM 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Form  1  (Directory  Name) 

0/M 

0/M 

1  ..  1024  octets 

1 

I2 

Form  2  (Object  ID) 

0/M 

M 

1  ..  64  octets 

1 

NOTES 

1 .  The  limits  specified  apply  to  the  AE-Title  which  is  the  combination  off  the  AP-Title  and  AE-Qualifier. 
They  are  specified  in  line  with  the  limits  given  in  Part  3  on  the  Atomic-Action  Identifier  and  the  Branch 
Identifier. 
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C.11.  AUTHENTICATION  VALUE  FORM 


Table  11  •  AUTHENTICATION  VALUE  FORM 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFSLE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1             iGraphic  String 

c/c 

2 

Bit  String 

c/c 

3 

External 

c/c 

4 

Any  Defined  By 

c/c 
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Introduction 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concemed  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-5:  OSI  Distributed  Transaction  Processing. 

Part  5:  APPLICATION  SUPPORTED  TRANSACTIONS  -  POLARIZED  CONTROL 
(ATP11) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  Application  Supported  Transaction  while  the 
application  is  using  the  Polarized  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP1 1  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Application  Supported  Distributed  Transactions,  where  the  applications 
take  responsibility  for  ensuring  that  transaction  semantics  are  maintained,  and  for  restoring  consistency 
after  any  failure.  The  dialogue  between  the  applications  is  subject  to  strict  turn  control.  The  handshake 
facility  is  available. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  identified  in  the  table  hereafter: 


DIALOGUE 

POLARIZED  CONTROL 
HANDSHAKE 


mandatory 
mandatory 
mandatory 


It  conforms  to  the  Application  Transactions  conformance  class  defined  in  ISO  10026-3. 
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6.  SCENARIO 

The  applicability  of  the  ATP1 1  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP11 

7.       USAGE  OF  UNDERLYING  STANDARDS 


This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below.  The  use  of 
ISO/I  EC  9804/9805  (CCR)  by  a  referencing  specification  is  forbidden  and  is  a  protocol  error. 


Application  Layer 

ISO  10026-3:1992  (081  TP) 
ISO  8650  ^  (ACSE) 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 

Session  Layer 

ISO  83273 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  ACSE,  Presentation  and  Session  PDUs  for  ATP1 1  is  as  described  in  Parts 
1.2  and  4  of  this  standard. 

9.  CONFORMANCE 

Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1.  ISO/lEC  JSP  12061-2,  ISO/IEC  ISP 
12061 -4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  1 2061 .  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

•  ISO/IEC  10026-4  (OSITP) 

•  ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 


3To  be  published 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  conrputer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concemed  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  fomi  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  OCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  1 0  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International 
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Part  6:  APPLICATION  SUPPORTED  TRANSACTIONS  -  SHARED  CONTROL 
(ATP12) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  Application  Supported  Transaction  while  the 
application  is  using  the  Shared  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP12  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Application  Supported  Distributed  Transactions,  where  the  applications 
take  responsibility  for  ensuring  that  transaction  semantics  are  maintained,  and  for  restoring  consistency 
after  any  failure.  The  dialogue  between  the  applications  is  not  subject  to  turn  control.  The  support  of  the 
handshake  facility  is  optional. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


DIALOGUE 
SHARED  CONTROL 
HANDSHAKE 


mandatory 
mandatory 
optional 


It  conforms  to  the  Application  Transactions  conformance  class  defined  in  ISO  10026-3. 
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6.  SCENARIO 

The  applicability  of  the  ATP12  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP12 

7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below.  The  use  of 
ISO/IEC  9804/9805  (CCR)  by  a  referencing  specification  is  forbidden  and  is  a  protocol  error. 


Application  Layer 

ISO  10026-3:1992  (OSITP) 
ISO  8650  1  (ACSE) 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 

Session  Layer 

ISO  8327^ 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  ACSE,  Presentation  and  Session  PDUs  for  ATP12  is  as  described  in  Parts 
1 ,2  and  4  of  this  standard. 

9.  CONFORMANCE 

Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISP 
1 2061  -4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  1 2061 ,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 
•       ISO/IEC  10026-4  (OSI  TP) 


"^To  be  published 


2 


Part  1 5  -  Transaction  Processing  December  1 992  (Stable) 

Profile  ATP12  PDISP  1 2061  -6 


•  ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 

•  ISO/IEC  8327-2  (Session) 
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INTRODUCTION 


The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 

interconnection  standards,  the  interconnection  of  computer  systems 
a.     from  different  manufacturers, 
I  b.      under  different  management, 

i  c.     of  different  levels  of  complexity, 

I  d.     of  different  technologies. 

I    Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 

j    a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  fomri  a  protected  indivisible  set. 


I     This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

I  Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

{    Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 

II  Part  5  to  10. 

! 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  1 0. 

i     Parts  5  to  1 0  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  international 
Standardized  Profiles  12061-7:  OSI  Distributed  TRANSACTION  PROCESSING. 


Part  7:  PROVIDER  SUPPORTED  UNCHAINED  TRANSACTIONS  -  POLARIZED 
CONTROL  (ATP21) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  unchained  sequences  of  Provider  Supported 
Transaction  branches  while  the  application  is  using  the  Polarized  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP21  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider  of  the 
OSI  TP  service  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for  restoring  consistency 
after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Unchained  sequence  of  Provider 
Supported  Transaction  Branches.  The  dialogue  between  the  applications  is  subject  to  strict  turn  control. 
The  handshake  facility  is  available. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functk>nal  units  as  shown  hereafter: 


DIALOGUE 

mandatory 

POLARIZED  CONTROL 

mandatory 

HANDSHAKE 

mandatory 

COMMIT 

mandatory 

UNCHAINED  TRANSACTIONS 

mandatory 

RECOVERY 

mandatory 

It  conforms  to  the  Unchained  Provider  Supported  Transaction  Branches  conformance  class  defined  in 
ISO  10026-3. 
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6.  SCENARiO 

The  applicability  of  the  ATP21  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP21 

7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  1  (ACSE) 
ISO  9805:1 990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 
ISO  8823  AM5 

Session  Layer 

ISO  83275 
ISO  8327  AM3 

8.       DETAILED  DESCRIPTION 


The  support  of  the  OSI  TP,  CCR,  ACSE.  Presentation  and  Session  PDUs  for  ATP21  is  as  described  in 
Parts  1  -  4  of  this  standard. 

9.  CONFORMANCE 


Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISP 
1 2061  -3,  ISO/IEC  ISP  1 2061  -4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

ISO/IEC  10026-4  (OSI  TP) 

ISO/IEC  9805-2  (CCR) 


^To  be  published 
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•  ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 

•  ISO/IEC  8327-2  (Session) 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  fonn  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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information  Technology  -  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-8:  OSI  Distributed  Transaction  Processing. 


Part  8:  PROVIDER  SUPPORTED  UNCHAINED  TRANSACTIONS  -  SHARED 
CONTROL  (ATP22) 


1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  Unchained  sequences  of  Provider  Supported 
Transaction  branches  while  the  application  is  using  the  Shared  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP22  Is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider  of  the 
OSI  TP  service  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for  restoring  consistency 
after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Unchained  sequence  of  Provider 
Supported  Transaction  Branches.  The  dialogue  between  the  applications  is  not  subject  to  turn  control. 
The  support  of  the  handshake  facility  is  optional. 

5.  }JSE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


It  conforrfis  to  the  Unchained  Provider  Supported  Transactions  Branches  conformance  class  defined  In 
ISO  10026-3. 


DIALOGUE 
SHARED  CONTROL 
HANDSHAKE 
COMMIT 

UNCHAINED  TRANSACTION 
RECOVERY 


mandatory 
mandatory 
mandatory 


mandatory 
mandatory 
optional 


1 


Part  15  -  Transaction  Prcxiessing 
Profile  ATP22 


December  1992  (Stable) 
PDISP  12061-8 


6.  SCENARIO 

The  applicability  of  the  ATP22  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP22 

7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  1  (ACSE) 
ISO9805:1990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1988(Presentation) 
ISO  8823  AM5 

Session  Layer 

ISO  83276 
ISO  8327  AM3 

8.       DETAILED  DESCRIPTION 


The  support  of  the  OSI  TP,  CCR,  ACSE,  Presentation  and  Session  PDUs  for  ATP22  is  as  described  in 
Parts  1  -  4  of  this  standard. 

9.  CONFORMANCE 


Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/I  EC  ISO/IEC 
ISP  1 2061  -3,  ISP  1 2061  -4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  1 2061 ,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

•  ISO/IEC  10026-4  (OSI  TP) 

•  ISO/IEC  9805-2  (CCR) 

•  ISO/IEC  8650-2  (ACSE) 


^To  be  published 
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•  ISO/IEC  8823-2  (Presentation) 

•  ISO/IEC  8327-2  (Session) 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  OCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-9:  OSI  Distributed  Transaction  Processing. 


Part  9:  PROVIDER  SUPPORTED  CHAINED  TRANSACTIONS  -  POLARIZED 
CONTROL  (ATP31) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  chained  sequences  of  Provider  Supported 
Transaction  branches  while  the  application  is  using  the  Polarized  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP31  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider  of  the 
OSI  TP  sen/ice  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for  restoring  consistency 
after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Chained  Sequence  of  Provider  Supported 
Transaction  Branches.  The  dialogue  between  the  applications  is  subject  to  strict  turn  control.  The 
handshake  facility  is  available. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


It  conforms  to  the  Chained  Provider  Supported  Transaction  Branches  conformance  class  defined  in 
ISO  10026-3. 


DIALOGUE 

POLARIZED  CONTROL 

HANDSHAKE 

COMMIT 

CHAINED  TRANSACTION 
RECOVERY 


mandatory 
mandatory 
mandatory 
mandatory 
mandatory 
mandatory 
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6.  SCENARIO 

The  applicability  of  the  ATP31  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP31 

7.       USAGE  OF  UNDERLYiNG  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  1  (ACSE) 
ISO  9805:1 990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 
ISO  8823  AM 5 

Session  Layer 

ISO  8327^ 
ISO  8327  AM3 

8.       DETAILED  DESCRIPTION 


The  support  of  the  OSI  TP,  CCR,  ACSE,  Presentation  and  Session  PDUs  for  ATP31  is  as  described  in 
Parts  1  -4  of  this  standard. 

9.  CONFORMANCE 


Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISO/IEC 
ISP  12061-3,  ISP  12061-4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

•  ISO/IEC  10026-4  (OSI  TP) 

•  ISO/IEC  9805-2  (CCR) 
ISO/IEC  8650-2  (ACSE) 


^To  be  published 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  forni  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  10. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  international 
Standardized  Profiles  12061-10:  OSi  Distributed  Transaction  Processing. 


Part  10:  PROVIDER  SUPPORTED  CHAINED  TRANSACTIONS  -  SHARED 
CONTROL  (ATP32) 


1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  chained  sequences  of  Provider 
Supported  Transaction  branches  while  the  application  is  using  the  Shared  Control  paradigm  for 
communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP32  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider 
of  the  OSI  TP  service  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for 
restoring  consistency  after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Chained 
sequence  of  Provider  Supported  Transaction  Branches.  The  dialogue  between  the  applications 
is  not  subject  to  turn  control.  The  support  of  the  handshake  facility  is  optional. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


It  conforms  to  the  Chained  Provider  Supported  Transaction  Branches  conformance  class  defined 
in  ISO  10026-3. 


DIALOGUE 
SHARED  CONTROL 
HANDSHAICE 
COMMIT 

CHAINED  TRANSACTION 
RECOVERY 


mandatory 
mandatory 
mandatory 


mandatory 
mandatory 
optional 
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6.  SCENARIO 

The  applicability  of  the  ATP32  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP32 

7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  1  (ACSE) 
ISO  9805:1 990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 
ISO  8823  AM 5 

Session  Layer 

ISO  83278 
ISO  8327  AM3 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  CCR.  ACSE,  Presentation  and  Session  PDUs  for  ATP32  is  as 
described  in  Parts  1  -  4  of  this  standard. 

9.  CONFORMANCE 

Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC 
ISO/IEC  ISP  1 2061  -3,  ISP  1 2061  -4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061 ,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

•  ISO/IEC  10026-4  (OSI  TP) 

•  ISO/IEC  9805-2  (CCR) 


^To  be  published 
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•  ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 

•  ISO/IEC  8327-2  (Session) 
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15.12.  OIW  Application  Contexts 

15.12.1.       Application  context  name 

Title:  UDT  with  Commit  Profiles 

Object  identifier:{iso(1)  identified-organization(3)  oiw(14)  tpsig(15) 

application-context(5)  udt-with-CCR(l)  version  1(0)} 

1 5.1 2.1 .1 .  Purpose  and  Scope 

The  purpose  of  this  application  context  is  to  provide  the  TPSUs  participating  in  a  TP  dialogue 
with  a  mechanism  for  exchanging  unstructured  data  by  mapping  it  onto  an  APDU  consisting  of  a 
simple  octet  string.  A  bilateral  agreement  will  be  required  between  two  cooperating  TPSUIs 
using  this  context  since  the  syntax  and  semantics  of  the  application  protocol  are  not  defined  here. 

This  application  context  supports  both  application  and  provider  supported  transactions  executed 
serially  over  the  same  association. 

The  use  of  the  base  standards  identified  here  is  restricted  by  the  specification  of  the  OSI  TP 
profiles. 

15.12.1.2.  Referenced  Standards 

This  application  context  definition  references  in  whole  or  in  part  the  following  specifications: 

ISO/IEC  10026-3:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  -  Part  3:  Protocol  specification 

ISO/IEC  10026-5:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  Protocol  -  Part  5:  Application  Context  Proforma  and  Guidelines  When 
using  OSI  TP 

ISO/IEC  10026-6:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  Protocol  -  Part  6:  Unstructured  Data  Transfer 

ISO/IEC  8650  Second  edition,  Information  Technology  -  Open  Systems  Interconnection  - 
Association  Control  Service  Element 

ISO/IEC  9805-1 :1990,  Information  Technology  -  Open  Systems  Interconnection  -  Protocol 
Specification  for  Commitment,  Concurrency  and  Recovery  Service  Elements 

ISO/IEC  9805-1  AM2:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Protocol 
Specification  for  Commitment,  Concurrency  and  Recovery  Service  Elements,  Amendment  2. 

ISO/IEC  PDISP  12061,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  ISP 

15.12.1.2.1.  Referenced  application  contexts 
None 
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1 5.1 2.1 .3.     Components  ASEs  and  ASOs 

The  following  ASEs  are  contained  in  this  application  context: 
ACSE 
TP-ASE 
CCR 
UDT 

15.12.1.3.1.  Association  Control  Service  Eiement  (ACSE) 

15.12.1.3.1.1.  References 

ISO/IEC  12061  part  4 

ISO/I  EC  8650  Second  Edition 

15.12.1.3.1.2.  Version  Number 

Version  1  of  the  ACSE  protocol  is  used. 

15.12.1.3.1.3.  Brief  description 

ACSE  is  used  to  establish  and  terminate  associations.  The  ACSE  functions  are  not  exercised 
directly  by  UDT  or  through  the  TP  sen/ice,  but  are  exercised  by  association  management 
facilities  within  the  TP  service  provider. 

15.12.1.3.2.  Distributed  Transaction  Processing  ASE  (TP-ASE) 

15.12.1.3.2.1.  References 

ISO/IEC  1 2061  -2  and  1 2061  -3 
ISO/IEC  10026-3 

15.12.1.3.2.2.  Version  Number 

Version  1  of  the  OSI  TP  protocol  is  used. 

15.12.1.3.2.3.  Brief  description 

OSI  TP  provides  communications  mechanisms  for  the  support  of  processing  transactions  across 
two  or  more  separate  systems. 

15.12.1.3.3.  Commitment,  Concurrency  and  Recovery  (CCR) 
15.12.1.3.3.1.  References 

ISO/IEC  12061-3, 
ISO/IEC  9805-1  and 
ISO/IEC  9805-1  AM2 
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15.12.1.3.3.2.  Version  Number 

Version  2  of  the  CCR  protocol  is  used. 

1 5.1 2.1 .3.3.3.  Brief  description 

CCR  is  used  in  support  of  the  commitment,  rollback  and  recovery  functions.  Only,  TP  makes  use 
of  the  CCR  ASE  services. 

15.12.1.3.4.  Unstructured  Data  Transfer  ASE  (UDT) 

15.12.1.3.4.1.  References 

ISO/IEC  10026-6. 

15.12.1.3.4.2.  Version  Number 

Version  1  of  the  UDT  protocol  is  used. 

15.12.1.3.4.3.  Brief  description 

This  ASE  transfers  unstructured  (i.e.  structure  unknown  to  the  TPPM)  data  between  cooperating 
TPSUIs. 

15.12.1.3.4.4.  Use  of  ottier  ASEs  or  ASOs 

None 

1 5.1 2.1 .4.  Persistent  application  context  ruies 

None 

15.12.1.5.  Control  function  rules 
15.12.1.5.1.  SACF  ruies 

15.12.1.5.1.1.  Objective/summary 

There  are  no  SACF  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC  10026-3. 

15.12.1.5.1.2.  Temporal  ordering  rules 

There  are  no  SACF  temporal  ordering  mles  beyond  those  specified  in  the  base  standard, 
ISO/IEC  10026-3  for  the  TP-DATA  generic  service. 

15.12.1.5.1.3.  Concatenation  ruies 

There  are  no  SACF  concatenation  mles  beyond  those  specified  in  the  base  standard,  ISO/IEC 
10026-3. 
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15.12.1.5.1.4.  Mapping  rules 

The  UDT-TRANSFER-RI  APDU  may  be  mapped  onto  P-DATA,  the  User-Data  parameter  of  the 
TP-BEGIN-DIALOGUE  sen/ice,  or  the  User-Data  parameter  of  TP-U-ABORT  service.  There  are 
no  state  transitions  beyond  those  specified  in  the  base  standard,  ISO/IEC  10026-3  for  the  TP- 
DATA  generic  service. 

1 5.1 2.1 .5.1 .5.  References  to  base  rules 

ISO/IEC  10026-3 

1 5.1 2.1 .5.1 .6.  Other  rules 

None 

15.12.1.5.2.  MACF  rules 

15.12.1.5.2.1.  Objective/summary 

There  are  no  MACF  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC  10026-3. 

15.12.1.5.2.2.  Temporal  ordering  rules 

There  are  no  MACF  sequencing  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC 
10026-3. 

15.12.1.5.2.3.  Concatenation  rules 

There  are  no  MACF  concatenation  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC 
10026-3. 

15.12.1.5.2.4.  Mapping  rules 

There  are  no  MACF  mapping  rules. 

1 5.1 2.1 .5.2.5.  References  to  base  rules 

ISO/IEC  10026-3 

1 5.1 2.1 .5.2.5.1 .      Other  rules 

None 

15.12.1.5.3.  Optional  features 

None 

15.12.1.5.4.  Error  handling 

For  this  application  context,  if  the  rules  and  constraints  of  the  application  context  are  violated  and 
the  commit  functional  unit  has  been  selected,  the  transaction  should  be  rolled  back.  If  the 
commit  functional  unit  is  not  selected,  the  TP-U-ERROR  service  may  be  used  or  the  dialogue 
may  be  aborted  depending  on  the  severity  of  the  error. 
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15.12.1.5.5.  Conformance 

Conformance  to  this  application  context  consists  of  conformance  to  ISO/IEC  POISP  12061  and 
ISO/IEC  10026-6. 

15.12.1.5.6.  Collision  handling 

No  collision  handling  rules  beyond  those  of  ISO/IEC  10026-3  are  required. 
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15.12.2.      Application  context  name 

Title:  Application  Supported  Transactions  using  UDT 

Object  identifier:{iso(1)  identified-organization(3)  oiw(14)  tpsig(15) 

application-context(5)  udt-without-CCR(2)  version1(0)} 

15.12.2.1.  Purpose  and  Scope 

The  purpose  of  this  application  context  is  to  provide  the  TPSUs  participating  in  a  TP  dialogue 
with  a  mechanism  for  exchanging  unstructured  data  by  mapping  it  onto  an  APDU  consisting  of  a 
simple  octet  string.  A  bilateral  agreement  will  be  required  tietween  two  cooperating  TPSUIs 
using  this  context  since  the  syntax  and  semantics  of  the  application  protocol  are  not  defined  here. 

This  application  context  supports  application  supported  transactions  executed  serially  over  the 
same  association. 

The  use  of  the  base  standards  identified  here  is  restricted  by  the  specification  of  the  OSI  TP 
profiles. 

15.12.2.2.  Referenced  Standards 

This  application  context  definition  references  in  whole  or  in  part  the  following  specif icatbns: 

ISO/IEC  10026-3:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  -  Part  3:  Protocol  specification 

ISO/IEC  10026-5:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  Protocol  -  Part  5:  Application  Context  Proforma  and  Guidelines  When 
using  OSI  TP 

ISO/IEC  10026-6:1992,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  Protocol  -  Part  6:  Unstructured  Data  Transfer 

ISO/IEC  8650  Second  edition.  Information  Technology  -  Open  Systems  Interconnection  - 
Association  Control  Service  Element 

ISO/IEC  PDISP  12061 ,  Information  Technology  -  Open  Systems  Interconnection  -  Distributed 
Transaction  Processing  ISP 

15.12.2.3.  Referenced  application  contexts 
None 

15.12.2.4.  Components  ASEs  and  ASOs 

The  following  ASEs  are  contained  in  this  application  context: 
ACSE 
TP-ASE 
UDT 
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15.12.2.4.1.  Association  Control  Service  Element  (ACSE) 

15.12.2.4.1.1.  References 

ISO/IEC  12061  part  4 
ISO/IEC  8650  Second  Edition 

1 5.1 2.2.4.1 .2.  Version  Number 

Version  1  of  the  ACSE  protocol  is  used. 

15.12.2.4.1.3.  Brief  description 

ACSE  is  used  to  establish  and  terminate  associations.  The  ACSE  functions  are  not  exercised 
directly  by  UDT  or  through  the  TP  service,  but  are  exercised  by  association  management 
facilities  within  the  TP  service  provider. 

15.12.2.4.2.  Distributed  Transaction  Processing  ASE  (TP-ASE) 

1 5.1 2.2.4.2.1 .  References 

ISO/IEC  1 2061  -2  and  1 2061  -3 
ISO/IEC  10026-3 

1 5.1 2.2.4.2.2.  Version  Number 

Version  1  of  the  OSI  TP  protocol  is  used. 

15.12.2.4.2.3.  Brief  description 

OSI  TP  provides  communications  mechanisms  for  the  support  of  processing  transactions  across 
two  or  more  separate  systems. 

15.12.2.4.3.  Unstructured  Data  Transfer  ASE  (UDT) 

15.12.2.4.3.1.  References 

ISO/IEC  10026-6. 

15.12.2.4.3.2.  Version  Number 

Version  1  of  the  UDT  protocol  is  used. 

15.12.2.4.3.3.  Brief  description 

This  ASE  transfers  unstructured  (i.e.  structure  unknown  to  the  TPPM)  data  between  cooperating 
TPSUIs. 

15.12.2.4.4.  Use  of  other  ASEs  or  ASOs 

None 
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15.12.2.5.  Persistent  application  context  rules 

None 

15.12.2.6.  Control  function  rules 

15.12.2.6.1.  SACF  rules 

15.12.2.6.1.1.  Objective/summary 

There  are  no  SACF  rules  beyond  those  specified  in  the  base  standard,  ISO/I  EC  10026-3. 

15.12.2.6.1.2.  Temporal  ordering  rules 

There  are  no  SACF  temporal  ordering  rules  beyond  those  specified  in  the  base  standard, 
ISO/IEC  1 0026-3  for  the  TP-DATA  generic  service. 

15.12.2.6.1.3.  Concatenation  rules 

There  are  no  SACF  concatenation  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC 
10026-3. 

15.12.2.6.1.4.  Mapping  rules 

The  UDT-TRANSFER-RI  APDU  may  be  mapped  onto  P-DATA.  the  User-Data  parameter  of  the 
TP-BEGIN-DIALOGUE  service,  or  the  User-Data  parameter  of  TP-U-ABORT  service.  There  are 
no  state  transitions  beyond  those  specified  in  the  base  standard,  ISO/IEC  10026-3  for  the  TP- 
DATA  generic  service. 

1 5.1 2.2.6.1 .5.  References  to  base  rules 

ISO/IEC  10026-3 

1 5.1 2.2.6.1 .6.  Other  rules 

None 

15.12.2.6.2.  MACF  rules 

15.12.2.6.2.1.  Objective/summary 

There  are  no  MACF  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC  10026-3. 

15.12.2.6.2.2.  Temporal  ordering  rules 

There  are  no  MACF  sequencing  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC 
10026-3. 

15.12.2.6.2.3.  Concatenation  rules 

There  are  no  MACF  concatenation  rules  beyond  those  specified  in  the  base  standard,  ISO/IEC 
10026-3. 
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15.12.2.6.2.4.  Mapping  rules 

There  are  no  MACF  mapping  rules. 

15.12.2.6.2.5.  References  to  base  rules 

ISO/IEC  10026-3 

15.12.2.6.2.6.  Other  rules 

None 

15.12.2.6.3.  Optional  features 

None 

15.12.2.6.4.  Error  handling 

For  this  application  context,  If  the  mies  and  constraints  of  the  application  context  are  violated  the 
TP-U-ERROR  service  may  be  used  or  the  dialogue  may  be  aborted  depending  on  the  severity  of 
the  error. 

15.12.2.6.5.  Conformance 

Conformance  to  this  application  context  consists  of  conformance  to  ISO/IEC  PDISP  12061  and 
ISO/IEC  10026-6. 

15.12.2.6.6.  Collision  handling 

No  collision  handling  rules  beyond  those  of  ISO/IEC  10026-3  are  required. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture 
Special  Interest  Group  (ODASIG)  of  the  Open  Systems  Environment  Implementors'  Worl<shop  (01 W). 

Text  in  this  part  has  k>een  approved  by  the  Plenary  of  the  above-mentioned  Workshop. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  struckout.  New  and  replacement  text  will  be  sfiown  as 
shaded. 
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Part  16  -  Office  Document  Architecture  Level  3  DAP 

NOTE  -  Text  for  the  International  Standardized  Profile  11182-1  (F0D36)  follows  this  page. 

This  Agreement  provides  a  Document  Application  Profile  which  has  been  developed  through  the 
joint  efforts  of  ODA  expert  groups  within  the: 

OSE  Implementors'  Workshop  (01 W); 

Asia-Oceania  Workshop  (AOW); 

European  Workshop  for  Open  Systems  (EWOS); 

CCITT  Study  Group  VIII. 

This  effort  was  conducted  through  meetings  of  the  Profile  Alignment  Group  for  ODA  (PAGODA)  for 
the  purpose  of  facilitating  the  intenA/orking  of  applications  which  interchange  documents  based  on 
[ISO  8613  I  T.410  series  of  CCITT  Recommendations].  This  Agreement  specifies  one  of  the 
profiles  resulting  from  that  work: 

ISO/IEC  ISP  1 11 82-1 : 1 992,  Information  technology-  Standardized  Profile  FOD36  -  Office  Document 
Format:  Extended  document  structure  -  Character,  raster  graphics  and  geomentric  graphics  content 
architectures  -  Document  Application  Profile. 


This  Agreement  accepts  the  entirety  of  the  definitions  and  provisions  of  this  ISP  as  the  agreement 
for  the  OIW  Stable  Agreements  and  the  standards  upon  which  the  specified  ISP  is  based  as 
referenced  by  the  text  of  the  ISP.  For  this  reason  the  text  of  the  ISP  is  not  reproduced  here,  but 
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Foreword 


Development  of  this  document  application  profile  has  been  done  in  liaison  with  several  organizations. 
These  include  ODA  expert  groups  within  the: 

—  Asia-Oceania  Workshop  (AOW); 

—  CCITT  Study  Group  VIII; 

—  European  Workshop  for  Open  Systems  (EWOS); 

—  OSE  Implementors  Workshop  (OIW). 

The  liaison  between  these  organizations  has  occurred  within  the  meetings  of  the  Profile  Alignment  Group 
for  ODA  (PAGODA).  These  meetings  have  focused  on  the  development  of  a  single  set  of  internationally 
aligned  ODA  document  application  profiles. 

The  profile  defined  in  this  ISP  is  a  part  of  the  ODA  profile  taxonomy  defined  in  TR  10000-2,  4.4.4.3  and 
5.4.1.  This  profile  is  specific  to  the  profile  identifier  FOD36. 

At  present,  this  ISP  consists  of  one  part: 

Part  1:  Document  application  profile. 

Further  parts  may  be  added  to  this  ISP. 

This  part  contains  three  annexes: 

—  Annex  A  (normative):  Amendments  and  corrigenda; 

—  Annex  B  (informative):  Recommendations; 

—  Annex  C  (informative):  Bibliography, 
introduction 

The  purpose  of  this  International  Standardized  Profile  (ISP)  |  CCITT  Recommendation  is  to  facilitate  the 
interwotking  of  applications  interchanging  documents  based  on  (ISO  8613  |  T.410  series  of  CCITT 
Recommendation],  ODA.  This  ISP  named  FOD36  |  CCITT  Recommendation  named  PM-36  is  suitable  for 
interchanging  documents  in  formatted  form,  processable  form  or  formatted  processable  form  and  has  been 
defined  in  accordance  with  [ISO  8613-1  |  CCITT  Recommendation  T.41 1).  The  format  of  this  profile  is  in 
accordance  with  the  standardized  proforma  and  notation  defined  in  Addendum  1  -  Annex  F  of  (ISO  8613-1 
I  CCITT  Recommendation  T.411]. 

The  specification  of  FOD36  is  identical  to  the  specification  of  PM-36.  except  that  PM-36  only  defines  the 
use  of  the  ODIF  interchange  format. 
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PROCESSABLE  FORMS 

Document  Application  Profile 


1  Scope 

This  profile  specifies  interchiange  formats  for  the  transfer  of  structured  documents  between  equipment 
designed  for  word  or  document  processing.  Such  documents  may  contain  character,  raster  graphics 
and  geometric  graphics  content. 

The  documents  that  can  be  interchanged  using  this  profile  range  from  simple  documents  to  highly 
structured  technical  reports,  articles  and  typeset  documents  such  as  brochures.  This  profile  provides  a 
comprehensive  level  of  features  for  the  transfer  of  documents  between  these  systems. 

This  profile  allows  documents  to  be  interchanged  in  the  following  forms: 

a)  formatted  form; 

b)  processable  form; 

c)  formatted  processable  form. 

The  architecture  levels  defined  for  these  three  forms  have  matching  functionalities  so  that  the 
interchange  formats  of  a  document  are  convertible  from  a  processable  form  to  any  other  form. 

This  profile  is  independent  of  the  processes  carried  out  in  an  end  system  to  create,  edit  or  reproduce 
documents.  It  is  also  independent  of  the  means  to  transfer  documents  which,  for  example,  may  be  by 
means  of  communication  links  or  storage  media. 

( 

NOTE  1  -  The  following  texts  apply  to  the  ISP  only. 

A  document  structured  in  accordance  with  this  profile  is  represented  for  interchange  by  one  of  two 
DAPs.  One  DAP  uses  the  Office  Document  Interchange  Format  (ODIF),  the  other  DAP  uses  the  Office 
Document  Language  (ODL).  both  as  defined  in  ISO  8613-5. 

When  this  document  refers  to  this  profile,  it  is  referring  to  either  of  the  document  application  profiles 

defined  by  this  specification. 

) 


2  Normative  references 


The  following  documents  contain  provisions  which,  through  reference  in  this  text,  consititute  provisions 
of  this  Specification.  At  the  time  of  publication,  the  editions  indicated  were  valid.  All  documents  are 
subject  to  revision,  and  parties  to  agreements  based  on  this  Specification  are  warned  against 
automatically  applying  any  more  recent  editions  of  the  documents  listed  below,  since  the  nature  of 
references  made  by  profiles  to  such  documents  is  that  they  may  be  specific  to  a  particular  edition. 
Members  of  lEC  and  ISO  maintain  registers  of  currently  valid  International  Standards  and  ISPs.  The 
CCITT  secretariat  maintains  a  list  of  the  currently  valid  CCITT  recommendations. 

ISO  8613-1  :  1989,  Information  Processing  -  Text  and  Office  Systems;  Office  Document  Arctiitecture 
(ODA)  and  Interctiange  Format  -  Part  1:  Introduction  and  General  Principles; 

ISO  8613-2  :  1989,  Information  Processing  -  Text  and  Office  Systems:  Office  Document  Arctiitecture 
(ODA)  and  Interchange  Format  -  Part  2:  Document  Structures: 

ISO  8613-4  :  1989,  Information  Processing  -  Text  and  Office  Systems;  Office  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  4:  Document  Profile, 

ISO  8613-5  ;  1989,  Information  Processing  -  Text  and  Office  Systems;  Office  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  5:  Office  Document  Interchange  Format; 

ISO  8613-6  :  1989,  Information  Processing  -  Text  and  Office  Systems;  Office  Document  Architecture 
(ODA)  and  Interchange  Format  ■  Part  6:  Character  Content  Architectures; 

ISO  8613-7  :  1989,  Information  Processing  -  Text  and  Office  Systems;  Office  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  7;  Raster  Graphics  Content  Architectures; 

ISO  8613-8  :  1989,  Information  Processing  -  Text  and  Office  Systems;  Office  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  8:  Geometric  Graphics  Content  Architectures; 

ISO  8613-1  Addendum  1  :  Information  Processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  Pari  1;  Introduction  and  General  Principles  Addendum  1  - 
Annex  F :  A  Document  Application  Profile  Proforma  and  Notation; 

CCITT  Recommendation  T.400  :  1988.  Introduction  to  Document  Architecture,  Transfer  and 
Manipulation; 

CCITT  Recommendation  T.411  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Introduction  and  General  Principles; 

CCITT  Recommendation  T.412  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Structures; 

CCITT  Recommendation  T.414  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Profile; 

CCITT  Recommendation  T.415  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Open  Document  Interchange  Format; 

CCITT  Recommendation  T.416  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Character  Content  Architecture; 

CCITT  Recommendation  T.417  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Raster  Graphics  Content  Architecture; 
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CCITT  Recommendation  T.418  :  1988.  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Geometric  Graphics  Content  Architecture; 

ISO/IEC  646  :  1991 ,  Information  technology  ■  ISO  7-bit  coded  character  set  for  information  interchange, 

ISO  8859-1  :  1987,  Information  Processing  -  8-bit  Single-byte  coded  graphic  character  sets  -  Part  1: 
Latin  alphabet  No.  1; 

ISO  6937-2  : 1983,  Information  Processing  -  Coded  character  sets  for  text  communication  -  Part  2: 
Latin  alphabetic  and  non-alphabetic  graphic  characters, 

ISO  6937-2  ADDENDUM  1  : 1989,  Information  Processing  -  Coded  character  sets  for  text 
communication  -  PART  2:  Latin  alphabetic  and  non-alphabetic  graphic  characters  ADDENDUM  1; 

ISO  2022  : 1986,  Information  Processing  -  ISO  7-bit  and  8-bit  coded  character  sets  -  Code  extension 
techniques, 

ISO  2375  : 1985,  Data  Processing  -  Procedure  for  registration  of  escape  sequences; 

ISO  7350  : 1984,  Text  communication  -  Registration  of  graphic  character  subrepertoires; 

ISO  8824  : 1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Abstract  Syntax 
Notation  One  (ASN.1); 

ISO  8825  : 1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic  encoding 
rules  for  abstract  syntax  notation  one  (ASN.  1); 

ISO  8879  : 1986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML); 

ISO  9069  : 1988,  Information  processing  -  SGML  support  facilities  -  SGML  Docunwnt  Interchange 
Format  (SDIF); 

CCITT  Recommendation  T.502  |  ISO/IEC  ISP  10610-1  : 1992,  Information  technology  ■  Standardized 
Profile  PM-11  /  F0D1 1  -  Open  Document  Format :  Simple  document  structure  -  Character  content 
architecture  only  -  Document  Application  Profile; 

CCITT  Recommendation  T.505  |  ISO/IEC  ISP  11181-1  : 1992,  Information  technology  ■  Standardized 
Profile  PM-26  /  FOD26  -  Open  Document  Format :  Enhanced  document  structure  -  Character,  raster 
graphics  and  geometric  graphics  content  architectures  -  Document  Application  Profile; 

CCITT  Recommendation  T.516  :  (to  be  published)  Implementation  requirement  for  document  application 
profile  PM-36; 

ISO/IEC  TR  10000-1  :  1990,  Information  Technology  -  Framework  and  Taxonomy  of  International 
Standardized  Profiles  -  Part  1:  Framework; 

ISO/IEC  TR  10000-2  : 1990,  Information  Technology  -  Framework  and  Taxonomy  of  Intemational 
Standardized  Profiles  -  Part  2:  Taxonomy, 
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3  Definitions 

For  the  purposes  of  this  Specification,  the  following  definitions  apply. 

The  definitions  given  in  [ISO'8613-1  |  CCITT  Recommendation  T.411]  are  applicable. 

Constituent  names 

Each  constituent  that  may  be  included  in  a  document  that  conforms  to  this  profile  has  been  given  a 
unique  name  which  serves  to  identify  that  constituent  throughout  this  profile. 

The  convention  is  that  full  names  are  used  (i.e.,  no  abbreviations  are  used),  two  or  more  words  in  a 
name  are  concatenated  and  each  word  begins  with  a  capital.  Examples  of  constituent  names  used  in 
this  profile  are  BodyText,  Footnote.  RectoPage  and  ColumnFixed. 

In  clause  6,  each  constituent  provided  by  this  profile  is  underlined  once  at  the  point  in  the  text  at  which 
the  purpose  of  that  constituent  is  defined.  This  also  serves  to  identify  all  the  constituents  provided  by 
this  profile. 

The  same  constituent  names  are  also  used  in  the  technical  specification  in  clause  7  so  that  there  is  a 
one-to-one  correspondence  between  the  use  of  these  names  in  clauses  6  and  7. 

Although  the  constituent  names  relate  to  the  purpose  of  the  constituents,  the  semantics  of  constituents 
shall  not  be  implied  from  the  actual  names  that  are  used.  Also,  these  names  do  not  appear  in  an 
interchanged  document  but  a  mechanism  for  identifying  constituents  in  an  interchange  document  is 
provided  (see  6.6.5).  Thus  in  an  application  using  this  profile,  the  constituents  may  be  known  to  the 
user  by  different  names. 


4  Relationship  with  other  profiles 

This  profile  belongs  to  a  series  of  hierarchically  related  profiles  which  include  PM-1 1  |  F0D1 1  and  PM- 
26  I  FOD26. 

The  features  supported  by  this  profile  are  a  superset  of  the  features  supported  by  the  profiles  PM-1 1  | 
F0D1 1  and  PM-26  |  FOD26  and  thus  all  data  streams  that  are  conformant  to  PM-1 1  |  F0D1 1  and  PM- 
26  I  FOD26  are  also  conformant  to  this  profile  apart  from  the  DAP  identifier. 


5  Conformance 

In  order  to  conform  to  this  profile,  a  data  stream  representing  a  document  must  meet  the  requirements 

specified  in  5.1 . 
( 

NOTE  2  -  The  following  text  applies  to  the  ISP  only. 

This  part  of  the  ISP  does  not  define  implementation  support  requirements.  These  requirements  are 

defined  in  other  parts  that  make  use  of  this  ISP. 

) 

( 

NOTE  3  -  The  foltowing  text  applies  to  the  CCITT  Recommendations  only. 

This  Recommendation  does  not  define  implementation  or  service  requirements.  These  requirements 
are  defined  in  other  Recommendations  that  make  use  of  this  profile. 


4 


5.1  Data  stream  conformance 


The  following  requirements  apply  to  the  encoding  of  data  streams  which  conform  to  this  profile: 

a)  (NOTE  4  -  The  following  text  applies  to  the  ISP  only. 

the  data  stream  shall  be  encoded  either  in  accordance  with  the  ASN.1  encoding  rules  defined 
in  (ISO  8825  |  CCITT  Recommendation  X.209]  or  the  SGML  encoding  rules  defined  in  ISO 

8879; 
) 

(NOTE  5  -  The  following  text  applies  to  CCITT  Recommendation  only. 

the  data  stream  shall  be  encoded  in  accordance  with  the  ASN.1  encoding  rules  defined  in 

[CCITT  Recommendation  X.209  |  ISO  8825]; 

) 

b)  the  data  stream  shall  be  structured  in  accordance  with  the  interchange  formats  defined 
in  clause  8; 

c)  the  document,  as  represented  by  the  data  stream  after  resolution  of  any  external 
references,  shall  be  structured  in  accordance  with  one  of  the  documents  architecture 
classes  as  defined  in  6.1  and  shall  contain  all  mandatory  constituents  specified  for  that 
class;  other  constituents  may  be  included,  provided  that  they  are  permitted  for  that 
class  as  specified  in  clause  7; 

d)  each  constituent  shall  contain  all  those  attributes  specified  as  required  for  that 
constituent  in  this  profile;  other  attributes  may  be  specified  provided  that  they  are 
permitted  for  that  constituent; 

e)  the  attribute  values  specified  shall  be  within  the  range  of  permissible  values  specified  in 
this  profile; 

f)  the  encoded  document  shall  be  constructed  in  accordance  with  the  abstract  document 

architecture  defined  in  [ISO  8613-2  |  CCITT  Recommendation  T.412]; 

g)  the  document  shall  be  structured  in  accordance  with  the  characteristics  and  constraints 
specified  in  clause  6. 


5.2  Implementation  conformance 

This  subclause  states  the  requirements  for  implementations  claiming  conformance  to  this  profile. 

( 

NOTE  6  -  The  following  text  applies  to  the  ISP  only. 

A  conforming  receiving  implementation  shall  be  capable  of  receiving  either  any  data  streams 
conforming  to  this  profile  structured  in  accordance  with  ODIF,  or  any  data  streams  conforming  to  this 
profile  structured  in  accordance  with  ODL  or  both  of  these.  Receiving  usually,  but  not  always.  Involves 
recognizing  and  further  processing  the  data  stream  elements.  The  explicit  meaning  of  "receiving"  is 
determined  by  another  part  of  this  ISP. 
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A  receiving  system  which  claims  conformance  to  this  DAP  shall  be  capable  of  handling  data  streams 
which  are  conformant  to  DAPs  that  are  subordinate  to  this  DAP  within  the  taxonomy  described  in 
clause  4,  i.e.  F0D11  and  FOD26. 
) 

( 

NOTE  7  -  The  following  text  applies  to  the  ISP  only. 

The  implementation  requirements  associated  with  this  profile  are  defined  in  Recommendation  T.516. 
) 
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6  Characteristics  supported  by  this  document  application  profile 

This  clause  describes  the  characteristics  of  documents  which  may  be  represerrted  by  data  streams 
conforming  to  this  profile.  This  clause  also  describes  how  these  characteristics  are  represented  in 
terms  of  constituent  constraints. 

6.1  Overview 

6.1.1  General 

This  profile  supports  the  interchange  of  documents  in  the  following  forms: 

—  processable  form,  which  facilitates  the  revision  of  a  document  by  a  recipient; 

—  formatted  form,  which  facilitates  the  reproduction  of  a  document  as  Intended  by  the 
originator; 

—  formatted  processable  form,  which  facilitates  the  reproduction  of  a  document  as 
intended  by  the  originator  or  facilitates  the  revision  of  a  document  by  a  recipient; 

In  addition  this  profile  supports  the  interchange  of: 

—  generic-document; 

—  document  profile. 

The  constituents  that  make  up  these  five  classes  of  data  stream  are  defined  in  6.1 .2  to  6.1 .6. 
Constituents  defined  as  'required'  shall  occur  in  any  data  stream  that  conforms  to  this  profile. 
Constituents  listed  as  optional*  may  or  may  not  be  present  in  the  data  stream  depending  on  the 
requirements  of  the  particular  data  stream. 

NOTE  8  -  The  constituents  that  make  up  a  complete  data  stream  that  is  conformant  to  this  profile  includes  all 
those  referenced  and  contained  in  resource  and  external  documents,  if  any  (see  6.6.1  and  6.6.2). 

6.1.2  Formatted  form  documents 

Required  constituents: 

—  a  document  profile; 

—  layout  object  descriptions  representing  a  specific  layout  structure. 
Optional  constituents: 
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—  layout  object  class  descriptions  representing  a  'factor*  generic  layout  structure; 

—  presentatbn  styles; 

—  content  portion  descriptions. 

6.1.3  Processabie  form  documents 

Required  constituents: 

—  a  document  profile; 

—  logical  object  class  descriptions  representing  a  'complete'  or  partial'  generic  logical 
structure; 

—  logical  object  descriptions  representing  a  specific  logical  stmcture. 
Optional  constituents: 

—  layout  object  class  descriptions  representing  a  'complete'  generic  layout  structure; 

—  layout  styles;  ■  ir- 

—  presentation  styles; 

—  content  portion  descriptions. 

In  the  case  of  processabie  form  documents,  when  the  generic  layout  structure  Is  not  present,  additional 
restrictions  are  placed  on  the  layout  directives  that  may  t>e  included  in  layout  styles.  These  restrictions 
are  defined  in  6.4.3  of  this  profile. 

6.1.4  Fomfiatted  processabie  fomi  documents 

Required  constrtuents: 

—  a  document  profile; 

—  logical  object  class  descriptions  representing  a  complete'  or  partial'  generic  logical 
stojcture; 

—  logical  object  descriptions  representing  a  specific  logical  structure; 

—  layout  object  class  descriptions  representing  a  'complete'  generic  layout  structure; 

—  layout  object  descriptions  representing  a  specific  layout  structure. 
Optional  constituents: 

—  layout  styles; 

—  presentation  styles; 

—  content  portion  descriptions. 
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6.1.5  Generic  documents 

A  generic-document  consists  of  one  of  the  following  sets  of  constituents: 
a) 

—  a  document  profile; 

—  logical  object  class  descriptions  whicfi  represent  a  'complete'  or  partial'  generic  logical 
stnjcture; 

—  layout  styles  whose  presence  is  optional; 

—  presentation  styles  whose  presence  is  optional; 

—  generic  content  portions  whose  presence  is  optional. 

b) 

—  a  document  profile; 

—  layout  object  class  descriptions  which  represent  a  'complete'  generic  layout  stnicture  or 
factor  set'; 

—  presentation  styles  whose  presence  Is  optional; 

—  generic  content  portions  whose  presence  is  optional. 

c) 

—  a  document  profile; 

—  logical  object  class  descriptions  which  represent  a  'complete'  or  'partial'  generic  logical 
structure; 

—  layout  object  class  descriptions  which  represent  a  complete'  generic  layout  structure; 

—  layout  styles  whose  presence  is  optional; 

—  presentation  styles  whose  presence  is  optional; 

—  generic  content  portions  whose  presence  is  optional. 

« 

6.1.6  Document  profile 

This  form  of  document  contains  a  document  profile  only. 
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6.2  Logical  characteristics 


6.2.1  introduction 

This  sulxlause  defines  the  logical  constituent  constraints  provided  by  this  profile  to  represent  the 
characteristics  of  documents. 

Different  constituent  constraints  may  be  used  to  represent  and  distinguish  parts  of  a  document  that 
have  different  logical  characteristics.  This  subclause  describes  the  general  characteristics  and  typical 
uses  of  the  constituent  constraints  that  are  provided. 

The  descriptions  of  the  logical  characteristics  represented  by  each  of  the  constituent  constraints  is 
provided  for  guidance  only.  It  is  the  responsibility  of  the  user  to  determine  how  a  document  is  to  be 
represented  using  the  constituents  provided.  Adherence  to  these  guidelines  can  enhance  the  mutual 
understanding  of  a  document  by  an  originator  and  a  recipient. 


6.2.2  Overview  of  the  logical  structure 

From  the  logical  point  of  view,  the  document  consists  of  two  parts,  namely  a  'body'  part  and  a 

'common'  part. 

The  body'  part  represents  the  main  content  of  a  document  and  is  intended  to  be  reproduced  in  the 
tKDdy  area  of  the  pages  that  make  up  the  document.  The  body'  part  must  be  included  in  all  documents 
that  are  interchanged  in  accordance  with  this  profile. 

The  common'  part  represents  comnrwn  content  that  is  to  be  placed  in  reserved  header  and  footer 
areas  on  each  page  of  a  document.  Header  and  footer  content  are  independently  optional  and  so  may 

be  included  in  an  interchanged  document  only  if  required. 


6.2.3  Body  part  of  the  logical  structure 


6.2.3.1  DocumentLogicaiRoot 

DocumentLogicalRoot  is  a  constituent  constraint  representing  the  top  level  in  the  document  togical 
structure.  Its  immediate  subordinates  consist  of  an  arbitrary  ordered  sequence  of  one  or  more 
constituent  constraints  of  the  types  Passage  and  NumberedSegment. 

The  automatic  numbering  schemes  that  apply  to  constituent  constraints  of  the  types 
NumberedSegment,  Figure,  Table,  NumtjeredList  and  Footnote  may  be  initialized  on  the 
DocumentLogicalRoot. 


6.2.3.2  Passage 

Passage  is  a  constituent  constraint  that  represents  a  subdivision  of  a  document  that  corresponds  to  a 
logical  grouping  of  subordinate  parts  of  a  document.  This  grouping  may  be  regarded  as  a  logical  entity 
for  reading,  or  it  may  represent  parts  of  a  document  that  have  common  layout  and  presentation 
characteristics. 

Passages  are  typically  used  to  represent: 
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—  the  contents  to  be  placed  on  the  title  page  of  a  report; 

—  the  front  matter,  consisting  of  the  table  of  contents  or  foreword; 

—  the  main  matter  of  the  document; 

—  the  back  matter,  consisting  of  appendices,  glossary  or  index; 

—  an  illustration  with  associated  text  which  is  inserted  as  a  distinct  entity  within  a  section 
of  a  document. 

The  automatic  numbering  schemes  that  apply  to  sutx)rdinate  constituent  constraints  of  the  types 
NumberedSegment,  Figure,  Table.  NumberedList  and  Footnote  may  be  initialized  on  a  Passage. 

The  immediate  subordinates  of  a  Passage  consist  of  an  optional  constituent  constraint  of  the  type  Title 
which  is  followed  by  an  arbitrary  ordered  sequence  of  one  or  more  of  the  following  constituent 
constraints: 

—  Paragraph; 

—  BodyGeometric; 

—  BodyRaster; 

—  BodyText; 

—  Figure; 

—  Table; 

—  NumberedList; 

—  UnNumberedList; 

—  DefinitionList; 

—  NumberedSegment; 

—  Passage. 

A  Passage  shall  have  at  least  one  of  the  above  constituent  constraints  as  a  subordinate. 

Therefore,  a  Passage  may  itself  contain  one  or  more  subordinates  of  the  type  Passage,  and  thus 
Passages  may  be  nested  to  any  number  of  levels.  This  allows  logical  entities  within  a  document  to  be 
described  in  terms  of  their  component  logical  entities.  Also,  a  NumberedSegment  may  contain  one  or 
more  subordinate  Passages  which  allows  different  logical  entities  within  a  NumberedSegment  to  be 
distinguished. 

A  document  may  contain  several  different  class  definitions  of  the  type  Passage,  each  of  which  defines 
the  common  characteristics  of  sets  of  Passages  within  the  document,  such  as  their  allowed 
subordinates  or  layout  properties.  For  example,  a  class  of  Passages  may  be  defined  which  always 
begins  on  a  new  page  set. 
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6.2.3.3  NumberedSegment 


NumberedSegment  is  a  constituent  constraint  that  represents  a  logical  entity  within  a  document  that  is 
distinguished  by  an  identifier.  This  logical  entity  may  be  a  subdivision  of  a  document  or  a  higher  level 
Passage  or  NumberedSegment.  The  entity  may  also  be  distinguished  by  having  some  comnwn  layout 
characteristics. 

The  automatic  numt>ering  schemes  that  apply  to  the  subordinate  constituent  constraints 
NumberedSegment,  Figure,  Table,  NumberedList  and  Footnote  may  be  initialized  on  any  logical  object 
or  logical  object  class,  typically  on  Passage  or  a  NumberedSegment. 

The  immediate  subordinates  of  a  Numt>eredSegment  consist  of  the  constituent  constraint  Number 
whose  presence  is  mandatory  and  serves  to  carry  the  identifier  of  the  NumberedSegment.  This  is 
followed  optionally  by  a  constituent  constraint  Title  which  in  turn  is  followed  by  an  optional  arbitrary 
ordered  sequence  of  one  or  more  of  the  following  constituent  constraints: 

—  Paragraph; 

—  BodyGeometric; 

—  BodyRaster; 

—  BodyText; 

—  Figure; 

—  Table; 

—  NumberedList; 

—  UnNumberedList; 

—  DefinitionList; 

—  Passage; 

—  NumberedSegment. 

The  above  indicates  that  a  document  may  contain  any  number  of  nested  levels  of  the  constituent 
constraint  NumberedSegment. 

A  NumberedSegment  is  typically  used  to  represent  entities  such  as  chapters,  sections,  nested  sub- 
sections and  appendices  which  contain  an  identifier  that  serves  to  distinguish  that  entity  for  human 
comprehension. 

A  document  may  contain  any  number  of  different  class  definitions  of  NumberedSegment  which  define 
the  common  characteristics  of  sets  of  NumberedSegments.  such  as  their  allowed  subordinates  and 
layout  properties. 

Class  definitions  of  Numt>eredSegments  may  be  recursively  defined.  In  this  case,  only  one  class  of 
NumberedSegment  may  be  specified,  and  the  <simple-expr>  construction  in  the  macro 
USENUMBERSTRINGS  in  the  bindings  attribute  of  this  class  shall  use  the  optional  ORD  constmction 
only.  If  recursive  class  definitions  are  used  for  NumberedSegment,  the  following  constraints  will  also 
apply.  For  all  levels  which  reference  recursively  defined  classes: 
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—  numbering  format  will  be  the  same; 

—  no  initial  value  other  than  1  or  re-initialization  of  the  numt>ering  is  possible; 

—  it  is  not  possible  to  continue  the  numbering  across  Passages. 


6.2.3.4  Number 

Numt)er  is  a  constituent  constraint  that  represents  the  identifier  of  a  NumberedSegment,  Figure  or 
NumberedList  to  which  it  is  sutx)rdinate.  This  identifier  allows  the  superior  constituent  constraint  to 
which  It  belongs  to  t>e  distinguished  within  the  document  for  machine  processing  or  human 
comprehension. 

A  Numt)er  is  a  basic  logical  constituent  constraint  which  contains  a  content  generator  which,  when 
evaluated,  produces  the  identifier  referred  to  atx}ve.  This  evaluation  takes  place  during  the  layout 
process.  • 

The  identifiers  are  structured  and  consist  of  a  sequence  of  one  or  more  numerals  that  allow 
NumberedSegments  at  the  same  or  different  levels  in  a  document  structure  to  be  uniquely 
distinguished.  The  numerals  may  be  represented  by  Arabic  or  Roman  numerals  or  by  their  alphabetic 
equivalent  in  lower  or  upper  case  characters  (the  number  1  is  represented  by  'A',  etc.).  Each  numeral 
in  an  identifier  is  distinguished  by  means  of  'separator'  characters  such  as  spaces  and  full  stops  (the 
character  'period');  a  typical  example  is  '6.2.3.4'. 

NOTE  9  -  The  separator  may  be  an  empty  string. 

Further  details  of  the  structure  and  generation  of  the  identifiers  are  given  in  6.6.7. 


6.2.3.5  Title 

Title  is  a  constituent  constraint  that  is  used  to  represent  the  title,  heading  or  name  of  the  Passage  or 
NumberedSegment  to  which  it  is  an  immediate  sutx>rdinate.  This  constituent  constraint  may  consist  of 
character,  raster  graphics  and  geometric  graphics  content. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  an  arbitrary  ordered  sequence  of 
one  or  more  of  the  following  constituent  constraints: 

—  BodyText; 

—  BodyRaster; 

—  BodyGeometric: 

—  Phrase; 

—  Reference; 

—  Footnote. 

The  character  content  associated  with  a  Title  may  be  concatenated  to  form  a  continuous  stream  of 
character  content  which  may  contain  single  or  multiple  references  to  footnotes  or  other  parts  of  the 
document,  and  may  i^e  laid  out  as  single  unit.  Entities  within  this  content  which  have  particular  logical 
significance  or  presentation  features  may  be  distinguished  using  the  constituent  constraint  Phrase. 
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Content  from  any  sutxjrdinate  basic  text  objects  within  a  paragraph  may  be  run-on  one  from  another 
(that  is,  to  continue  on  the  same  line)  by  use  of  Concatentation  (see  6.4.2.5).  Alternatively,  content 
from  subordinates  of  a  paragraph  may  be  separated  one  from  another  to  give  white  space  between 
them,  using  Separation  (see  6.4.2.2).  This  may  be  used  to  give  an  effect  similar  to  that  achieved  with 
empty  lines  of  text.  Use  of  empty  text  lines  to  achieve  white  space  between  areas  of  text  or  other 
content  may  lead  to  unintended  blank  areas  adjacent  to  the  leading  edge  of  layout  objects,  whereas  the 
use  of  Separation  avoids  this. 


6.2.3.6  Paragraph 

Paragraph  is  a  constituent  constraint  that  is  a  subdivision  of  a  Passage  or  NumberedSegment.  It  is 
typically  used  to  represent  the  grouping  of  parts  of  a  document  that  deals  with  a  single  theme  or  topic. 
These  parts  may  consist  of  character,  raster  graphics  and  geometric  graphics  content. 

The  immediate  subordinates  of  a  Paragraph  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  of 
the  following  constituent  constraints: 

—  BodyText; 

—  BodyRaster; 

—  BodyGeometric; 

—  Phrase; 

—  Reference; 

—  Footnote. 

The  character  content  associated  with  a  Paragraph  may  be  concatenated  to  form  a  continuous  stream 
of  character  content  which  may  contain  single  or  multiple  references  to  footnotes  or  other  parts  of  the 
document,  and  may  be  laid  out  as  single  unit.  Entities  within  this  content  which  have  particular  logical 
significance  or  presentation  features  may  be  distinguished  using  the  constituent  constraint  Phrase. 

Content  from  subordinates  of  a  paragraph  may  be  separated  one  from  another  to  give  white  space 
between  them  using  Separation  (see  6.4.2.2).  This  may  be  used  to  give  an  effect  similar  to  that 
achieved  with  empty  lines  of  text.  Use  of  enpty  text  lines  to  achieve  white  space  t)etween  areas  of  text 
or  other  content  may  lead  to  unintended  blank  areas  adjacent  to  the  leading  edge  of  layout  objects 
(e.g.,  at  page  breaks)  whereas  the  use  of  Separation  avoids  this. 

6.2.3.7  Phrase 

Phrase  is  a  constituent  constraint  that  is  used  to  group  together  an  amount  of  character  content  that 
represents  a  single  logical  entity  that  needs  to  be  distinguished  for  some  purpose.  That  is,  the  content 
represented  by  a  Phrase  may  have  a  particular  logical  significance,  or  it  may  have  certain  layout  or 
presentation  requirements.  The  character  content  may  contain  embedded  footnotes  and  references  to 
other  parts  of  the  document  content.  A  typical  example  is  a  quotation  that  is  to  be  reproduced  in  italics. 

A  Phrase  may  be  used  as  subdivision  of  constituent  constraints  of  the  types  Paragraph,  Title,  Caption, 
Description,  Artwork  and  Listltem.  Also,  a  Phrase  may  be  subordinate  to  another  Phrase  and, 
therefore,  constituent  constraints  of  the  type  Phrase  may  be  nested. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  an  arbitrary  ordered  sequence  of 
one  or  more  of  the  following  constituent  constraints: 


14 


—  BodyText; 

—  Phrase; 

—  Reference; 

—  Footnote. 

The  character  content  associated  with  a  Phrase  may  be  concatenated  to  form  a  continuous  stream  of 
character  content  which  may  contain  single  or  multiple  references  to  footnotes  or  other  parts  of  the 
document,  and  may  be  laid  out  as  single  unit.  Alternatively,  the  character  content  may  contain  hard 
line  terminators,  which  will  cause  parts  of  the  content  to  be  separated  when  laid  out. 


6.2.3.8  BodyText,  BodyRaster  and  BodyGeometric 

* 

BodyText.  BodyRaster  and  BodyGeometric  are  constituent  constraints  which  represent  the  lowest  level 
of  logical  sutxlivision  of  a  document.  These  constituent  constraints  act  as  carriers  for  the  document 
content  and  may  be  specified  as  subordinates  of  constituent  constraints; 

—  Passage; 

—  NumberedSegment; 

—  Paragraph; 

—  Title; 

—  ListTerm; 

—  Artwork; 

—  Phrase; 

—  Reference; 

—  UnNumberedList. 

In  addition,  BodyText  may  be  specified  as  a  sut)ordinate  to  Phrase,  Caption  and  Description.  These 
constituent  constraints  allow  the  layout  and  presentation  requirements  of  different  parts  of  the  content  of 
a  document  to  be  specified. 

These  are  basic  logical  constituent  constraints  that  directly  refer  to  content  jwrlions  that  contain 
character,  raster  graphics  and  geometric  graphics  content  respectively.  BodyText  shall  refer  to  one  or 
more  content  portions  which  may  contain  either  processable,  formatted  or  formatted  processable 
character  content.  BodyRaster  and  BodyGeometric  shall  only  refer  to  a  single  content  portion 
containing  formatted  processable  raster  graphics  content  or  formatted  processable  geometric  graphics 
content  respectively. 

These  constituent  constraints  in  the  generic  logical  structure  may  refer  to  generic  content.  This 
provides  the  means  of  defining  common  content  within  the  body  part  of  a  document. 

Where  the  superior  constituent  constraint  referenced  is  sutx)rdinate  to  a  FootnoteBody,  it  is  required  to 
specify  one  of  the  layout  category  names  for  this  constituent  constraint.  Footnote'  or  'Footnote-<n>'. 
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This  along  with  a  Permitted  categories  attribute  of  the  same  name  on  the  footnote  frame  will  ensure 
that  a  logical  object  from  this  constituent  constraint  is  laid  out  in  a  FootnoteArea  frame  when  generic 
layout  structure  is  specified  within  the  document. 

6.2.3.9  Constituents  representing  footnotes 

This  subclause  defines  the  constituents  that  are  used  to  represent  footnotes. 


6.2.3.9.1  Footnote 


Footnote  is  a  constituent  constraint  that  is  used  to  represent  footnotes  within  a  document.  This 
constituent  constraint  may  be  specified  as  a  subordinate  to: 

—  Paragraph; 

—  Title: 

—  ListTerm; 

—  Phrase; 

—  Caption: 

—  Description. 

A  footnote  is  an  amount  of  content  that  is  logically  associated  with  a  particular  part  of  the  document 
body,  but  which  is  intended  to  be  read  and  laid  out  separately  from  its  associated  part  of  the  document. 
Typically,  a  footnote  consists  of  a  footnote  identifier,  which  is  embedded  within  the  document  body,  and 
the  footnote  itself,  which  is  laid  out  elsewhere. 

A  Footnote  is  a  composite  logical  constituent  constraint  whose  immediate  subordinates  consist  of  the 
constituent  constraint  FootnoteReference,  which  represents  the  footnote  identifier,  followed  by  the 
constituent  constraint  FootnoteBody.  which  represents  the  footnote  itself.  Both  of  these  subordinates 
are  mandatory. 

6.2.3.9.2  FootnoteReference 

FootnoteReference  is  a  constituent  constraint  that  is  used  to  represent  a  footnote  reference  within  the 
body  of  a  document. 

FootnoteReference  is  a  basic  logical  constituent  that  contains  a  content  generator  which,  when 
evaluated,  produces  a  character  string  which  constitutes  the  footnote  reference  refen-ed  to  at)Ove. 

The  generated  character  string  consists  of  a  \abe\  with  optional  prefix  and  suffix  character  strings.  The 
lat>el  is  used  to  uniquely  identify  a  particular  footnote,  and  may  consist  of  a  numt)er  which  is 
represented  in  the  form  of  Arabic  or  Roman  numerals  or  by  an  alphabetic  equivalent.  The  number  may 
be  automatically  generated  so  that  its  value  is  incremented  for  each  successive  footnote.  Alternatively, 
the  label  may  consist  of  a  user  defined  character  string. 

In  a  sequence  of  footnotes,  automatic  numbers  and  user  defined  labels  may  be  freely  mixed  (for 
example,  giving  the  sequence  1,2,*,3.4).  If  the  label  consists  of  a  user-defined  character  string,  the 
automatically  generated  number  sequence  is  not  incremented. 
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An  example  of  a  footnote  reference  is  "(2)'  where  '('  and  ')*  are  user  defined  prefix  and  suffix  strings 
respectively  and  '2'  Is  \Ue  automatically  generated  label.  Anotfier  example  is  note^'  where  '5'  is  the 
label  and  note'  is  a  prefix  string  which  also  contains  the  control  function  PLU  to  enable  the  label  to  be 
represented  in  the  form  of  a  superscript.  In  this  case,  a  suffix  string  containing  the  control  function  PLD 
would  be  required  to  cause  the  superscripting  to  be  cancelled  before  the  following  text. 

The  format  of  the  content  generator  referred  to  above  is  described  in  6.6.7.7. 


6.2.3.9.3  FootnoteBody 

FootnoteBodv  is  a  constituent  constraint  which  represents  the  content  of  a  footnote.  The  content 
consists  of  a  stream  of  character  content  which  may  contain  embedded  references  to  other  parts  of  the 
document. 

FootnoteBody  is  a  composite  logical  constituent  constraint  whose  subordinates  consist  of  the 
constituent  constraint  FootnoteNumber,  which  is  mandatory  and  represents  the  footnote  identifier, 
followed  by  a  sequence  of  one  or  more  constituent  constraints  of  the  type  FootnoteText  and  Reference 
which  represent  the  footnote  content.  The  identifier  referred  to  above  is  identical  to  the  corresponding 
footnote  identifier  which  is  embedded  in  the  content  of  the  document  body  and  represented  by  the 
constituent  constraint,  FootnoteReference. 

The  constituent  constraints  sutwrdinate  to  FootnoteBody  are  intended  to  be  laid  out  separately  from  the 
other  parts  of  the  document  content.  When  a  generic  layout  structure  is  specified  for  the  document, 
these  constituent  constraints  are  constrained  to  be  laid  out  in  a  FootnoteArea  frame  (see  6.3.5.20). 


6.2.3.9.4  FootnoteNumber 

FootnoteNumber  is  a  constituent  constraint  that  represents  the  footnote  identifier  within  the  footnote 
body. 

This  identifier  is  Identical  to  the  content  associated  with  the  constituent  constraint  FootnoteReference, 
but  is  intended  to  be  laid  out  so  that  it  immediately  precedes  the  content  of  the  footnote  body. 

FootnoteNumber  is  a  basic  logical  constituent  constraint  that  contains  a  content  generator  which  when 
evaluated  produces  the  identifier  referenced  above.  The  format  of  this  content  generator  is  the  same 
as  the  content  generator  that  may  be  specified  for  the  constituent  constraint  FootnoteReference. 

It  is  required  to  specify  one  of  the  layout  category  names  for  this  constituent  constraint,  'Footnote'  or 
'Footnote-<n>'.  This  along  with  a  permitted  categories  attribute  of  the  same  name  on  the  footnote 
frame  will  ensure  that  a  logical  object  from  this  constituent  constraint  is  laid  out  in  a  FootnoteArea 
frame  when  generic  layout  structure  is  specified  within  the  document. 


6.2.3.9.5  FootnoteText 

Footnotetext  is  a  constituent  constraint  that  is  used  to  represent  the  footnote  content.  It  is  the  lowest 
logical  subdivision  of  a  FootnoteBody. 

FootnoteText  is  a  basic  logical  constituent  constraint  that  references  one  or  more  content  portions  each 
containing  processable,  formatted  or  formatted  processable  character  content. 
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It  is  required  to  specify  one  of  the  layout  category  names  for  this  constituent  constraint,  Footnote'  or 
'Footnote-<n>".  This  along  with  a  permitted  categories  attribute  of  the  same  name  on  the  footnote 
frame  will  ensure  that  a  logical  object  from  this  constituent  constraint  is  laid  out  in  a  FootnoteArea 
frame  when  generic  layout  structure  is  specified  within  the  document. 

6.2.3.10  Constituents  that  provide  for  a  general  referencing  mechanism 

This  sutxiause  defines  the  constituent  constraints  that  are  provided  to  support  a  general  referencing 
mechanism  in  a  document. 


6.2.3.10.1  Reference 

A  Reference  is  a  constituent  constraint  which  represents  a  reference  consisting  of  character  content 
that  is  derived  either  fully  or  partially  from  another  part  of  the  document.  This  constituent  constraint 
provides  a  general  cross-referencing  mechanism  in  a  document. 

This  constituent  constraint  may  be  specified  as  a  sutwrdinate  to  constituent  constraints  of  the  types: 

—  Paragraph; 

—  Title; 

—  ListTerm; 

—  Phrase; 

—  Caption; 

—  Description; 

—  FootnoteBody. 

It  is  a  composite  constituent  constraint  whose  immediate  subordinates  may  consist  of  an  ordered 
sequence  of  constituent  constraints  of  the  types  BodyText,  ReferencedContent  and  BodyText. 

The  general  format  of  the  content  associated  with  a  constituent  constraint  of  the  type  Reference  is: 

[<prefix-string>]<reference-stnng>[<suffix-string>] 

The  prefix  and  suffix  strings  are  optional  and,  if  required,  are  represented  by  constituent  constraints  of 
the  type  BodyText.  The  reference  string  is  represented  by  the  constituent  constraint, 

ReferencedContent. 

A  reference  string  may,  for  example,  contain  references  to  identifiers  such  as  a  number  that 
distinguishes  a  chapter  or  section,  a  table,  a  figure,  a  footnote,  an  item  in  a  numbered  list  or  a  page 
number.  Each  reference  may  contain  multiple,  concatenated  references  to  different  parts  of  a 
document;  a  typical  example  is  the  reference  'see  table  3  in  chapter  2  on  page  4'  where  the  values  '3'. 
'2'  and  '4  are  derived  automatically  from  the  appropriate  table,  chapter  and  page  in  the  document. 
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6.2.3.10.2  ReferencedContent 


ReferencedContent  is  a  constituent  constraint  that  represents  a  character  string  that  contains  a  single 
reference  to  content  in  other  parts  of  the  document  (see  6.2.3.10.1). 

It  is  a  basic  logical  constituent  constraint  that  is  an  immediate  subordinate  to  the  constituent  constraint 
Reference.  It  contains  a  content  generator  which,  when  evaluated,  produces  the  character  string 
containing  the  referenced  content. 

A  sequence  of  two  or  more  constituent  constraints  of  this  type  may  be  used  to  represent  a  composite 
reference  string  such  as  see  table  2  in  section  3.1  beginning  on  page  6",  where  the  strings  '2*.  '31'  and 
'6'  are  automatically  generated  by  referring  to  number  strings  attached  to  particular  parts  of  the 
document. 

The  format  of  this  content  generator  and  its  evaluation  is  described  in  6.6.7.9. 

Where  the  superior  constituent  constraint  referenced  is  subordinate  to  a  FootnoteBody,  it  is  required  to 
specify  one  of  the  layout  category  names  for  this  constituent  constraint.  Footnote'  or  'footnote-<n>'. 
This  along  with  a  permitted  categories  attribute  of  the  same  name  on  the  footnote  frame  will  ensure  that 
a  logical  object  from  this  constituent  constraint  is  laid  out  in  a  FootnoteArea  frame  when  generic  layout 
structure  is  specified  within  the  document. 

6.2.3.1 1  Constituents  representing  illustrations 


6.2.3.11.1  Introduction 

This  profile  supports  the  representation  of  illustrations  or  figures  consisting  of  artwork  or  simple  forms. 

Artwork  typically  consists  of  a  diagram  or  figure  which  is  an  image  composed  of  a  single  content  type 
or  which  is  formed  by  overlaying  two  or  more  separate  images  consisting  of  character,  raster  graphics 
or  geometric  graphics  content. 

A  form  typically  consists  of  a  collection  of  logical  entities,  each  of  which  has  a  certain  logical 
significance.  Each  logical  entity  may  be  further  sutxlivided  into  sutx)rdinate  logical  entities.  A  typical 
example  is  an  order  form  consisting  of  a  reference  number,  information  about  the  originator,  including 
the  name,  address  and  telephone  number,  a  list  of  items  required  and  their  expected  delivery  dates. 

The  entities  which  make  up  a  form  are  intended  to  be  laid  out  in  a  designated  area  which  is  sutxlivided 
into  areas  that  are  specially  reserved  for  each  particular  type  of  entity.  This  designated  area  is 
specified  by  the  frame  FormArea  when  the  generic  layout  structure  is  present  in  the  document. 

Optionally,  an  illustration  may  also  contain  an  identifier  which  may  be  used  to  distinguish  the  illustration 
from  other  parts  of  the  document,  a  caption  which  may  be  used  to  identify  the  purpose  of  the 
illustration,  and  an  amount  of  associated  descriptive  text. 

Further  information  concerning  the  layout  of  illustrations  consisting  of  artwork  or  forms  is  given  in 
6.4.1.3.7. 

The  constituent  constraints  used  to  represent  illustrations  are  defined  below. 
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6.2.3.11.2  Figure 


Figure  is  a  constituent  constraint  that  is  typically  used  to  represent  an  illustration.  Such  an  illustration 
may  consist  of  artwork  or  a  form  as  descrilDed  in  6.2.3.11.1. 

A  Figure  is  a  composite  logical  constituent  constraint  which  may  be  specified  as  a  sutx>rdinate  to  a 
Passage  or  NumberedSegment. 

The  subordinates  of  a  Figure  may  consist  of  a  sequence,  in  any  order,  of  the  following  constituent 
constraints: 

—  erther  Artwori<  or  Form; 

—  Number; 

—  Caption; 

—  Description. 

A  constituent  constrain!  of  the  type  Artwork  or  Form  must  always  be  present  as  a  subordinate  to  the 
constituent  constraint  Figure.  Constituent  constraints  of  the  types  Number,  Caption  and  Description  are 
independently  optional.  The  constituent  constraints  may  occur  in  any  order,  except  that  a  Nunt>er  and 
a  Caption  shall  be  in  this  order. 


6.2.3.11.3  Attwortt 

Artwork  is  a  constituent  constraint  that  is  typically  used  to  represent  a  graphical  image  within  an 
illustration  or  figure.  This  may  be  a  simple  image  that  is  represented  by  character,  raster  graphics  or 
geometric  graphics  content,  or  it  may  be  a  composite  image  consisting  of  a  combination  of  these 
content  types. 

This  constituent  constraint  shall  only  occur  as  a  subordinate  to  a  constituent  constraint  of  the  type 
Figure. 

The  immediate  sutx)rdinates  of  Artwork  consist  of  an  art>ltrary  ordered  sequence  of  one  or  more  of  the 
foHowing  constituent  constraints: 

—  Phrase; 

—  BodyRaster; 

—  BodyGeometric. 

The  constituent  constraint  Phrase  is  used  to  enable  the  image  to  contain  character  content  which 
contains  references  to  footnotes  or  other  parts  of  the  document. 


6.2.3.11.4  Form 

Porm  is  a  constituent  constraint  that  is  used  to  represent  a  simple  form  within  an  illustration  or  figure.  It 
is  a  composite  logical  constituent  constraint  which  shall  only  occur  as  a  subordinate  to  a  constituent 
constraint  of  the  type  Figure. 
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A  Form  consists  of  an  arbitrary  order  sequence  of  basic  entries  and  composite  entries.  Basic  entries, 
which  may  consist  of  character,  raster  graphics  or  geometric  graphics  content,  are  represented  by 
subordinate  constituent  constraints  of  the  type  EntryElement.  Composite  entries  are  represented  by 
subordinate  constituent  constraints  of  the  type  EntryGroup. 

Constituent  constraints  of  the  type  EntryGroup  may  be  further  subdivided  into  a  set  of  one  or  more 
basic  or  composite  entries.  Thus  a  composite  entry  may  be  nested  to  any  number  of  levels  such  that 
each  level  may  consist  of  a  set  of  subordinate  basic  and  composite  entries. 

This  profile  does  not  define  a  mechanism  for  defining  the  semantics  associated  with  each  basic  or 
composite  entry.  This  can  be  achieved  by  individual  applications  by  making  use  of  the  parameter 
"external  data"  in  the  attribute  "application  comments"  (see  6.6.5). 


6.2.3.11.5  Caption 

Caption  Is  a  constituent  constraint  that  typically  represents  a  title  or  header  that  is  associated  with  an 
illustration  or  figure.  This  constituent  constraint  represents  character  content  that  may  contain 
embedded  references  to  footnotes  and  to  other  content  within  the  document. 

A  Caption  is  a  composite  logical  constituent  constraint  which  shall  only  occur  as  a  sutwrdinate  to  a 
constituent  constraint  of  the  type  Figure. 

The  immediate  subordinates  of  a  Caption  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  of 
the  following  constituent  constraints: 

—  BodyText; 

—  Reference; 

—  Phrase; 

—  Footnote. 

The  atKDve  constituent  constraints  may  be  concatenated  to  form  a  continuous  stream  of  character 
content  which  is  to  be  laid  out  as  a  single  unit. 


6.2.3.11.6  Description 

Description  is  a  constituent  constraint  that  typically  represents  some  general  supplementary  information 
that  forms  part  of  an  illustration  that  contains  a  figure  or  form. 

This  constituent  constraint  is  a  composite  logical  constituent  constraint  which  shall  only  occur  as  a 
sutxjrdinate  to  a  constituent  constraint  of  the  type  Figure. 

The  immediate  subordinates  of  a  Description  consist  of  an  arbitrary  ordered  sequence  of  one  or  more 
of  the  following  constituent  constraints: 

—  BodyText; 

—  Reference; 

—  Phrase; 
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—  Footnote. 


The  above  constituent  constraints  may  be  concatenated  to  form  a  continuous  stream  oil  character 
content  which  is  to  be  laid  out  as  a  single  unit. 


6.2.3.11.7  EntryGroup 

EntryGroup  is  a  constituent  constraint  that  represents  a  composite  logical  entry  within  a  form. 

it  is  a  composite  logical  constituent  constraint  which  shall  only  occur  as  a  subordinate  to  a  constituent 
constraint  of  the  types  Form  or  EntryGroup. 

The  immediate  sulx)rdinates  of  a  EntryGroup  consist  of  an  arbitrary  ordered  sequence  of  one  or  more 
constituent  constraints  of  the  types  EntryElement  and  EntryGroup.  Therefore,  the  sut>ordinates  to 
EntryGroup  may  be  nested  to  any  number  of  levels. 

NOTE  10  -  Constituent  constraint  EntryElement  is  defined  in  6.2.3.12.6. 


6.2.3.12  Constituents  used  to  represent  tables 


6.2.3.12.1  Introduction 

For  the  purpose  of  this  profile,  a  table  is  a  logical  entity  that  consists  of  an  ordered  sequence  of 
elements,  called  cells',  that  are  arranged  into  a  two  dimensional  array  of  rows  and  columns. 

Each  row  may  consist  of  a  'simple'  row  which  contains  a  sequence  of  one  or  more  cells'.  Alternatively, 
a  row  may  consist  of  a  'composite'  row  which  contains  a  single  cell  followed  by  a  sequence  of  one  or 
more  subrows,  each  of  which  contains  a  sequence  of  cells'. 

The  subclauses  betow  define  the  logical  constituents  used  to  represent  tables.  Figure  28  illustrates  the 
stnjctural  relationships  between  the  constituents  used  to  represent  a  table.  Subclause  6.4.1 .3.8 
describes  how  tables  are  intended  to  be  laid  out. 


6.2.3.12.2  Table 

Table  is  a  logical  constituent  constraint  that  represents  a  table  as  a  whole.  This  constituent  constraint 
may  be  specified  as  a  subordinate  to  constituent  constraints  Passage  and  Numt>eredSegment. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  a  sequence  of  constituent 
constraints  Row.  Each  row  may  or  may  not  have  the  same  characteristics  with  regard  to  its  sub- 
structure. 


6.2.3.12.3  Row 

Row  is  a  constituent  constraint  that  is  a  subordinate  of  the  constituent  constraint  Table  and  represents 
a  row  of  entries  in  a  table.  This  may  consist  of  a  sequence  of  entries,  or  it  may  consist  of  a  single 
entry  followed  by  a  sequence  of  subrows  of  entries. 

In  order  to  represent  these  two  cases,  the  immediate  sutx)rdinates  of  a  Row  may  consist  of  either; 


22 


—  a  sequence  of  constituent  constraints  EntryElement,  or; 

—  a  single  constituent  constraint  EntryElement,  followed  by  a  single  constituent  constraint 
of  the  type  TableComponent. 


6.2.3.12.4  TableComponent 

TableComponent  is  a  constituent  constraint  that  is  a  subordinate  of  the  constituent  constraint.  Row,  and 
represents  a  sequence  of  one  or  more  subrows  of  entries  within  a  row  of  a  table. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  a  sequence  of  one  or  more 
constituent  constraints  of  the  type  RowComponent.  Each  RowComponent  shall  have  the  sanne 
characteristics  with  regard  to  its  sub-structure. 


6.2.3.12.5  RowComponent 

RowComponent  is  a  constituent  constraint  that  is  a  subordinate  of  the  constituent  constraint 
TableComponent  and  represents  a  sub-row  of  entries  in  a  row  of  entries  in  a  table. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  a  sequence  of  one  or  more 
components  of  the  type  EntryElement.  Each  EntryElement  may  or  may  not  have  the  same 
characteristics  with  regard  to  its  sub-structure. 


6.2.3.12.6  EntryElement 

EntryElement  is  a  constituent  constraint  that  represents  a  single  entry  in  a  form  or  table.  It  is  a  sub- 
division of  constituent  constraints  of  the  types  Table  and  Form.  In  the  case  of  Table,  it  is  specified  as  a 
subordinate  to  a  Row  or  a  RowComponent  and  represents  a  single  entry  in  a  table.  In  the  case  of 
Form,  ft  is  specified  as  a  subordinate  of  a  Form  itself  or  of  an  EntryGroup. 

Each  entry  in  a  table  or  form  may  consist  of  character,  raster  graphics  or  geometric  graphics  content 
and,  hence,  EntryElement  has  a  single  immediate  sut)ordinate  constituent  constraint  of  the  type 
EntryText,  EntryRaster  or  EntryGeometric. 


6.2.3.12.7  EntryText,  EntryRaster  and  EntryGeometric 

EntryText.  EntryRaster  and  EntryGeometric  are  constituent  constraints  which  represent  content  that  is 
to  be  entered  into  tables  and  forms.  These  constituent  constraints  may  be  specified  as  subordinates  of 
the  constituent  constraint  EntryElement  and  allow  the  layout  and  presentation  requirements  for  the 
content  allocated  to  tables  and  forms  to  be  specified. 

These  are  basic  logical  constituent  constraints  that  directly  refer  to  content  portions  that  contain 
character,  raster  graphics  and  geometric  graphics  content  respectively.  EntryText  shall  refer  to  one  or 
more  content  portions  which  may  contain  either  processable,  formatted  or  formatted  processable 
character  content.  EntryRaster  and  EntryGeometric  shall  only  refer  to  a  single  content  portion 
containing  formatted  processable  raster  graphics  content  or  formatted  processable  geometric  graphics 
content  respectively. 

Constituent  constraints  of  these  types  in  the  generic  logical  structure  may  refer  to  generic  content.  This 
provides  the  means  of  defining  common  content  within  tables  and  forms. 
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6.2.3.13  Constituents  representing  lists 


6.2.3.13.1  Introduction 

This  profile  supports  the  representation  of  three  types  of  lists,  as  follows: 

—  numbered  lists  consisting  of  ordered  lists  of  items,  each  of  which  is  preceded  by  an 
identifier  such  as  an  alphabetic  character  or  numeral; 

—  unnumbered  lists  consisting  of  unordered  lists  of  items,  each  of  which  may  optionally  be 
preceded  by  a  separator  such  as  a  hyphen,  bullet  or  small  circle; 

—  definition  lists  consisting  of  lists  of  ordered  pairs  of  items  such  as  a  term  and  its 
corresponding  definition. 

Each  type  of  list  may  be  nested  without  restriction,  and  one  particular  type  of  list  may  be  composed  of 
lists  of  other  types.  For  example,  an  item  in  a  numbered  list  can  consist  of  a  subordinate  numbered 
list,  unnumbered  list  or  definition  list. 

The  constituent  constraints  that  may  be  used  to  represent  these  list  types  are  defined  below. 


6.2.3.13.2  NumberedLlst 

A  NumberedList  is  a  constituent  constraint  that  is  used  to  represent  a  list  of  items,  each  of  which  is 
preceded  by  an  identifier  that  serves  to  distinguish  that  item. 

This  constituent  constraint  may  be  specified  as  an  immediate  subordinate  to  a  Passage, 
NumberedSegment,  or  Listltem. 

The  Immediate  subordinates  of  a  NumberedList  consist  of  the  constituent  constraint  Number  which 
contains  a  content  generator  that  generates  the  identifier  corresponding  to  each  item  in  the  list,  followed 
by  the  constituent  constraint,  Listltem.  This  pair  of  constituent  constraints  may  be  repeated  without 
limitation. 

Further  information  concerning  the  numbering  of  items  in  a  list  is  contained  in  6.6.7.5. 


6.2.3.13.3  UnNumberedLlst 

UnNumberedList  is  a  constituent  constraint  that  is  used  to  represent  a  list  of  items,  each  of  which  may 
be  preceded  by  an  optional  separator  consisting  of  character,  raster  graphics  or  geometric  graphics 
content. 

This  constituent  constraint  may  be  specified  as  an  immediate  subordinate  to  a  Passage, 
NumberedSegment,  or  Listltem. 

The  immediate  sulx)rdinates  of  an  UnNumberedList  consist  of  a  separator,  which  is  represented  by  a 
constituent  constraint  of  the  type  BodyText,  BodyRaster  or  BodyGeometric,  followed  by  the  constituent  ) 
constraint  Listltem.  This  pair  of  constituent  constraints  may  be  repeated  without  limitation. 
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6.2.3.13.4  DefinitionList 


DefinitionList  is  a  constituent  constraint  that  represents  a  sequence  of  ordered  pairs  of  items. 

This  constituent  constraint  may  be  specified  as  an  immediate  sutx)rdinate  to  a  Passage, 
Numt>eredSeQment.  or  Listltem. 

The  immediate  sutx>rdinates  of  this  item  consist  of  the  constituent  constraint  ListTerm,  folbwed  by  the 
constituent  constraint  Listltem.  This  pair  of  constituent  constraints  may  be  repeated  without  limitation. 


6.2.3.13.5  Listltem 

Listltem  is  a  constituent  constraint  that  represents  an  item  within  a  NumberedList,  UnNumberedList  or 
DefinitionList.  That  is,  this  constituent  constraint  represents  the  second  element  of  each  pair  of 
elements  within  a  numbered,  unnumbered  or  definition  list. 

The  immediate  subordinates  of  this  constituent  constraint  may  consist  of  a  sequence  of  one  or  more 
constituent  constraints  Phrase,  or  one  of  the  constituent  constraints  NumberedList,  UnNumt>eredList  or 
DefinitionList. 

Thus  this  constituent  constraint  represents  an  amount  of  character  content  that  may  contain  embedded 
references  to  footnote  and  other  parts  of  the  document,  or  it  represents  a  subordinate  list  of  items. 


6.2.3.13.6  ListTerm 

ListTerm  is  a  constituent  constraint  that  represents  a  term  element  within  a  DefinitionList.  A  term 
element  Is  the  first  item  of  each  pair  of  items  that  constitutes  a  definition  list. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  an  arbitrary  ordered  sequence  of 
one  or  more  of  the  following  constituent  constraints: 

—  BodyText; 

—  BodyRaster; 

—  BodyGeometric; 

—  Phrase; 

—  Reference; 

—  Footnote. 

Thus  this  constituent  constraint  represents  an  amount  of  character,  raster  graphics  and  geometric 
graphics  content.  Character  content  may  contain  embedded  phrases,  references  and  footnotes. 


6.2.4  Common  content  part  of  the  logical  structure 


25 


6.2.4.1  CommonContent 


CommonContent  is  a  constituent  constraint  that  represents  common  content  that  is  laid  out  in  the  body, 
header,  or  footer  area  of  the  pages  of  a  document.  Common  content  consists  of  any  combination  of 
character,  raster  graphics  and  geometric  graphics  content. 

Any  number  of  constituent  constraints  CommonContent  may  be  contained  in  a  document. 
CommonContent  is  a  composite  logical  object  class  whose  immediate  subordinates  consist  of  an 
arbitrary  ordered  sequence  of  one  or  more  of  the  following  constituent  constraints: 


—  CommonText; 

—  CommonRaster; 

—  CommonGeometric; 

—  CommonReference; 

—  Currentlnstance; 

—  TableNumber; 

—  PageNumber; 

—  CommonNumber. 

When  the  generic  layout  structure  is  present,  constituent  constraints  of  the  type  CommonContent  and 
their  associated  subordinate  constituent  constraints  are  constrained  to  be  laid  out  in  a  specified  frame 
within  a  body,  header  or  footer  area  using  the  'logical  source'  mechanism  (see  6.3.6). 


6.2.4.2  CommonText 

CommonText  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to  be  laid 
out  in  a  specified  area  within  a  page. 

CommonText  is  a  constituent  constraint  for  a  basic  logical  object  class  that  references  one  or  wore 
content  portions  each  containing  either  processable,  formatted  and  formatted  processable  character 
content. 


6.2.4.3  PageNumber 

PageNumber  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to  be  laid 
out  in  a  specified  area  in  a  page.  This  constituent  constraint  is  specifically  used  when  it  is  required  to 
represent  an  automatically  generated  page  number. 

PageNumber  is  a  basic  logical  object  class  that  contains  a  content  generator.  This  content  generator 
contains  a  reference  to  a  page  number  which  is  automatically  evaluated  when  the  document  is  laid  out. 
For  example,  this  provides  the  means  of  representing  the  page  numbers  that  are  displayed  on  the 
consecutive  pages  of  a  document. 
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Each  page  number  consists  of  a  single  number  which  may  be  represented  in  the  form  of  Arabic  or 
Roman  numerals  or  in  its  alphabetic  equivalent.  Page  numbering  schemes  may  start  at  0  or  any  value 
greater  than  0.  The  page  number  that  is  generated  may  have  a  prefix  or  suffix  character  string. 

The  format  of  the  content  generators  is  defined  in  6.6.7.8. 


6.2.4.4  CommonRaster 

CommonRaster  is  a  constituent  constraint  that  represents  the  common  raster  graphics  content  that  is  to 
be  laid  out  in  a  specified  area  within  a  page.  For  example,  this  constituent  constraint  may  be  used  to 
represent  a  logo  which  is  to  be  laid  out  on  each  page  of  a  document. 

Common  raster  is  a  constituent  constraint  for  a  basic  logical  object  class  which  references  a  single 
content  portion  containing  formatted  processable  raster  graphics  content. 


6.2.4.5  CommonGeometric 

CommonGeometric  is  a  constituent  constraint  that  represents  the  common  geometric  graphics  content 
that  is  to  be  laid  out  in  a  specified  area  within  a  page.  For  example,  this  constituent  constraint  may  be 
used  to  represent  a  graphical  icon  which  is  to  be  laid  out  on  each  page  of  a  document. 

CommonGeometric  is  a  constituent  constraint  for  a  basic  logical  object  class  which  references  a  single 
content  portion  containing  formatted  processable  geometric  graphics  content. 


6.2.4.6  CommonReference 

CommonReference  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to 
be  laid  out  in  a  specified  area  in  a  page  and  which  represents  a  character  string  that  contains 
references  to  other  parts  of  the  document.  Such  a  reference  may  consist  of  a  reference  to  a  number 
that  relates  to  a  segment,  table,  figure,  footnote  or  page  number. 

CommonReference  is  a  constituent  constraint  for  a  basic  logical  object  class  that  contains  a  content 
generator  which,  when  evaluated,  produces  a  character  string  containing  the  references.  The  format  of 
this  reference  string  is  defined  in  6.6.7.10. 


6.2.4.7  Currentlnstance 

Currentlnstance  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to  be 
laid  out  in  a  specified  area  in  a  page.  This  constituent  constraint  is  specifically  used  when  it  is  required 
to  refer  to  a  character  string  that  is  attached  to  any  logical  constituent  constraint  in  the  document  or  any 
of  the  layout  constituent  constraints  DocumentLayoutRoot,  PageSet,  RectoPage,  VersoPage  or  Page. 
The  number  string  may  represent,  for  example,  the  title  of  a  sub-section  or  table  that  is  contained 
elsewhere  in  the  document. 

Currentlnstance  is  a  constituent  constraint  for  a  basic  logical  object  class  that  contains  a  content 
generator  which,  when  evaluated,  produces  a  copy  of  the  character  string  associated  with  a  specified 
constituent.  The  format  of  this  reference  is  defined  in  6.6.7.1 1 . 
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6.2.4.8  TableNumber 


TableNumber  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to  be  laid 
out  in  a  specified  area  in  a  page.  This  constituent  constraint  is  specifically  used  when  it  is  required  to 
represent  a  table  number  which  is  to  be  placed  within  the  header  area  of  a  table. 

TableNumber  is  a  constituent  constraint  tor  a  basic  logical  object  class  that  contains  a  content 
generator  which,  when  evaluated,  generates  the  required  table  number.  The  format  of  the  content 
generator  is  defined  in  6.6.7.6. 


6.2.4.9  CommonNumber 

CommonNumber  is  a  constituent  constraint  that  represents  the  common  character  content  that  is  to  be 
laid  out  in  a  specified  area  in  a  page.  This  constituent  constraint  is  specifically  used  when  it  is  required 
to  refer  to  character  content  consisting  of  a  number  string  which  can,  for  example,  represent  the 
number  of  a  sub-section  or  a  current  page. 

CommonNumber  is  a  constituent  constraint  for  a  basic  logical  object  class  that  contains  a  content 
generator  which,  when  evaluated,  generates  the  reference  to  the  required  number.  The  format  of  this 
reference  is  defined  in  6.6.7.12. 


6.3  Layout  characteristics 

This  sutx;lause  defines  the  layout  constituent  constraints  provided  by  this  profile  to  represent  the 
characteristics  of  documents. 

Different  constituent  constraints  may  be  used  to  represent  and  distinguish  parts  of  a  document  that 
have  different  layout  characteristics.  This  subclause  descrilDes  the  general  characteristics  and  typical 
uses  of  the  constituent  constraints  that  are  provided. 

The  descriptions  of  the  layout  characteristics  represented  by  each  of  the  constituent  constraints  Is 
provided  for  guidance  only.  It  is  the  responsibility  of  the  user  to  determine  how  a  document  is  to  be 
represented  using  the  constituents  provided.  Adherence  to  these  guidelines  can  enhance  the  mutual 
understanding  of  a  document  by  an  originator  and  a  recipient. 


6.3.1  Overview  of  the  layout  characteristics 

The  document  structure  allows  the  document  content  to  be  laid  out  and  presented  in  one  or  more  page 
sets.  Each  page  set  may  be  used  for  different  parts  of  the  document,  for  example,  the  title  page, 
foreword,  table  of  contents,  document  body  and  appendices. 

Each  page  set  consists  of  a  series  of  pages.  In  general,  each  page  may  be  sub-divided  into  three 
areas:  the  tx)dy  area,  which  is  used  to  layout  the  document  txDdy;  and  the  header  and  footer  areas, 
which  may  be  used  to  layout  the  common  content. 

NOTE  11  -  In  the  case  of  FOD36.  common  content  may  also  be  laid  out  in  the  body  area,  as  well  as  the 
header/footer  area. 

Three  tx)dy  layout  types  are  supported  by  this  profile.  Each  body  layout  type  specifies  how  the  body  is 
positioned  within  each  page,  and  how  the  content  may  be  presented  within  the  tx)dy.  These  are 
referred  to  as  b)ody  layouts  A,  B,  and  C,  and  are  defined  in  6.3.4.5. 
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It  is  Intended  that  all  applications  which  use  this  profile  shall  support  body  layout  A,  whereas  support  for 
the  other  two  body  layouts  may  be  specified  as  optional. 

Body  layout  A  is  used  when  the  character  content  is  to  be  laid  out  horizontally  (from  left  to  right  or  from 
right  to  left)  and  from  top  to  bottom  within  the  body  area.  This  layout  is  typically  used  for  contents 
written  in  Latin  based,  Hebrew,  Arabic,  and  Japanese  (most  cases)  languages. 

Body  layout  B  is  used  when  the  character  content  is  to  be  laid  out  vertically  (bottom  to  top  or  top  to 
t)Ottom)  and  from  left  to  right  within  the  t)ody  area.  This  layout  is  typically  used  for  contents  written  in 
Latin  based,  Hebrew,  Arabic,  and  Japanese  (most  cases)  languages  in  which  it  is  required  to  layout  the 
content  in  landscape  orientation  within  the  body  area  of  the  page. 

Body  layout  C  is  used  when  the  character  content  is  to  be  laid  out  vertically  and  from  right  to  left  within 
the  body  area.  This  layout  may  be  typically  used  for  contents  written  in  languages  which  use 
ideograms,  such  as  Japanese  and  Chinese  characters. 

The  body,  header  and  footer  areas  may  be  further  sub-divided  into  areas  to  support  a  wide  range  of 
different  layout  requirements.  These  features  are  described  further  in  6.3.5  and  6.3.6. 


6.3.2  DocumentLayoutRoot 

DocumentLavoutRoot  is  a  constituent  constraint  that  represents  the  top  level  in  the  document  layout 
structure.  Its  immediate  subordinates  consist  of  a  sequence  of  one  or  more  constituent  constraints  of 
the  type,  PageSet.  The  numbering  schemes  for  pages  may  be  initialized  on  this  constituent  constraint. 


6.3.3  PageSet 

PageSet  is  a  constituent  constraint  that  represents  a  grouping  of  pages  within  a  document.  A  PageSet 
is  typically  used  to  represent  a  part  of  a  document  that  has  different  layout  requirements  from  other 
parts  of  a  document.  Also,  a  PageSet  may  correspond  to  a  part  of  a  document  that  has  a  certain 
logical  significance,  for  example,  a  PageSet  might  represent  the  front  matter  in  a  document  or  an 
individual  chapter. 

Only  one  level  of  PageSet  is  allowed  in  a  document.  However,  a  document  may  contain  any  number  of 
class  definitions  of  the  type  PageSet  which  may  be  used,  for  example,  to  provide  a  choice  of  alternative 
layouts  for  different  parts  of  a  document  or  to  specify  the  exact  layout  requirements  for  each  successive 
part  of  a  document. 

The  immediate  subordinates  of  a  PageSet  consist  of  a  combination  of  constituent  constraints  of  the 
types  Page,  RectoPage  and  VersoPage,  as  described  in  6.3.4.1. 


6.3.4  Page  characteristics 


6.3.4.1  Page  constituents 

Three  constituent  constraints  are  provided  to  represent  the  pages  within  a  document,  namely  Page, 
Recto  Page  and  VersoPage. 

The  pages  that  make  up  a  page  set  consist  of  an  artDitrary  sequence  of  one  or  more  of  the  constituent 
constraints  Page,  RectoPage  and  VersoPage. 
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The  only  difference  in  the  characteristics  of  these  constituent  constraints  concerns  the  values  that  may 
be  specified  for  the  parameter  "side  of  sheet"  in  the  attribute  "medium  type".  In  the  case  of  Page,  the 
value  of  this  parameter  may  be  specified  as  recto",  verso'  or  unspecified'.  In  the  case  of  RectoPage, 
the  value  of  this  parameter  may  be  specified  as  recto'  or  unspecified";  in  the  case  of  VersoPage.  the 
value  of  this  parameter  may  be  specified  as  'verso'  or  unspecified".  The  values,  recto'  and  'verso',  of 
the  "side  of  sheet"  parameter  of  the  "medium  type"  attribute  are  non-basic. 

The  following  restrictions  also  apply  to  the  pages  within  a  page  set: 

a)  all  the  pages  shall  have  the  same  dimensions,  but  may  differ  in  orientation  (see 

6.3.4.2); 

b)  all  the  pages  are  to  be  laid  out  on  the  same  size  of  presentation  medium  (see  6.3.4.3); 

c)  all  the  pages  instantiated  from  a  given  page  class  shall  have  the  same  layout 
characteristics  (see  note).  That  is.  for  a  given  page  class,  there  is  not  a  choice  of 
layout  characteristics.  However,  the  layout  characteristics  of  pages  in  a  page  set  may 
or  may  not  be  the  same. 

NOTE  12  -  The  layout  characteristics  of  pages  are  specified  in  6.3.4.5.  Pages  having  the  same  layout 
characteristics  are  pages  for  which  the  body  area,  header  area  (if  present)  and  footer  area  (if  present)  have  the 
same  dimensions  and  position  within  the  page  (see  6.3.4.3).  However,  pages  having  the  same  layout 
characteristics  do  not  necessarily  have  the  same  position  on  the  presentation  medium  (see  6.3.4.4). 


6.3.4.2  Page  dimensions 

The  dimensions  of  the  pages  may  be  specified  as  any  value  (in  SMUs)  that  is  equivalent  to  or  less  than 
ISO  AO  or  ANSI  E  paper  sizes.  The  dimensions  may  be  specified  in  portrait  or  landscape  orientation. 
Japanese  page  sizes  B4  and  B5  are  also  supported,  but  the  dimension  of  these  pages  lie  within  the 
range  of  dimensions  given  above. 

Dimensions  equivalent  to  or  less  than  the  common  assured  reproduction  area  of  ISO  A4  and  ANSI-A  in 
portrait  or  landscape  orientation  are  basic  values.  Larger  page  sizes  are  non-basic  and  their  use  shall 
be  indicated  in  the  document  profile. 

Any  default  page  dimensions  may  be  specified  in  the  document  profile  subject  to  the  maximum 
dimensions  defined  above. 

NOTE  13  -  The  size  termed  "North  American  Letter  (NAL)"  in  [CCITT  Recommendation  T.410  series  |  ISO 
8613]  (e.g.,  in  [CCITT  Recommendation  T.412  |  ISO  8613-2]  clause  7)  is  called  "ANSI-A"  in  this  specification  to 
be  consistent  with  the  other  reference  to  ANSI  standard  paper  sizes. 


6.3.4.3  Nominal  page  sizes 

The  nominal  page  sizes  that  may  be  specified  are  listed  in  table  1 .  These  may  be  specified  in  portrait 
or  landscape  orientation.  All  values  of  nominal  page  size  are  non-basic  and  hence  all  values  used  in  a 
document  shall  be  indicated  in  the  document  profile. 

Any  value  of  nominal  page  size  defined  in  table  1 .  subject  to  the  restrictions  specified  above,  may  be 
specified  as  the  default  value  in  the  document  profile. 
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Table  1  also  includes  the  recommended  assured  reproduction  area  (ARA).  Information  loss  may  occur 
when  a  document  is  reproduced  if  the  dimensions  of  constituent  constraints  of  the  type  page  exceed 
the  ARA  for  the  specified  nominal  page  size. 


Table  1  —  Nominal  page  sizes 


Paae  tvnp 

Size  in  inches  or 
millimeters 

Si7P  in  BIUIIJ« 

wl4bC   II  1  UIVIW9 

ADA  in  BMUs 

ISO  A5 

148mm  x  210mm 

7015  X  9920 

not  defined 

ISO  A4 

210mm  X  297mm 

9920  X  14030 

9240  X  13200 

ISO  A3 

297mm  x  420mm 

14030  X  19840 

13200  X  18480 

ISO  A2 

420mm  x  594mm 

19840  X  28060 

18898  X  27118 

ISO  A1 

594mm  x  841mm 

28060  X  39680 

26173  X  37843 

ISO  AO 

841mm  X  1189mm 

39680  X  56120 

37843  X  54283 

ANSI  legal 

8.5in.  X  14in. 

10200  X  16800 

9240  X  15480 

ANSI  A 

8. Sin.  X  1  lin. 

10200  X  13200 

9240  X  12400 

ANSI  B 

11  in.  X  17jn. 

13200  X  20400 

12744  X  19656 

ANSI  C 

17in.  x22in. 

20400  X  26400 

19500  X  25800 

ANSI  D 

22in.  X  34in. 

26400  X  40800 

25800  X  39600 

ANSI  E 

34in.  X  44in. 

40800  X  52800 

39600  X  52200 

ANSI  F 

28in.  X  40in. 

33600  X  48000 

32400  X  47400 

Japan-legal 

257mm  x  364mm 

12141  X  17196 

11200  X  15300 

Japan-letter 

182mm  x  257mm 

8598  X  12141 

7600  X 10200 

6.3.4.4  Page  offset 

The  page  offset  is  the  distance  of  the  position  of  the  left  and  top  edges  of  the  page  relative  to  the  left 
and  top  edges  respectively  of  the  presentation  medium  on  which  each  page  is  reproduced.  Any  value 
of  page  offset  may  be  specified  provided  that  no  part  of  the  page  area  lies  outside  the  area  of  the 
nominal  page.  Also,  page  offsets  specified  for  the  initial,  recto  and  verso  pages  within  a  given  page  set 
may  differ.  The  default  page  offset  may  be  specified  in  the  document  profile. 


6.3.4.5  Page  layout  characteristics 

Each  page  in  a  document  may  be  subdivided  into  three  rectangular  areas,  as  follows: 
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—  a  body  area,  which  is  reserved  for  content  that  bebngs  to  the  body  part  of  the 

document  (see  6.3.5); 

—  a  header  area,  which  is  reserved  for  common  header  content  (see  6.3.6); 

—  a  footer  area,  which  is  reserved  for  comnwn  footer  content  (see  6.3.6). 

The  body  area  is  mandatory  and  shall  occur  on  every  page  in  a  document.  The  header  and  footer 
areas  are  tx)th  optional. 

Also  these  three  areas  shall  t>e  entirely  contained  within  the  page  area  and  must  not  overlap. 
Three  types  of  layout  of  body  area  are  defined: 

a)  Body  layout  type  A.  In  this  case,  the  layout  path  in  the  body  area  is  specified  as  270 
degrees. 

b)  Body  layout  type  B.  In  this  case,  the  layout  path  in  the  body  area  is  specified  as  0 
degrees. 

c)  Body  layout  type  C.  In  this  case,  the  layout  path  in  the  body  area  is  specified  as  180 
degrees. 

In  addition,  four  types  of  layout  of  header/footer  area  are  defined: 


a)  H/F  layout  A1 .  In  this  case,  the  layout  path  in  the  header  and  footer  area  is  270 
degrees.  If  the  header  or  footer  area  is  composite,  the  layout  paths  in  the  lowest 
frames  are  270  degrees; 

b)  H/F  layout  A2.  In  this  case,  the  layout  path  in  the  header  and  footer  area  is  0  degrees. 
If  the  header  or  footer  area  is  composite,  the  layout  paths  in  the  lowest  frames  are  270 
degrees; 

c)  H/F  layout  B1.  In  this  case,  the  layout  path  In  the  header  and  footer  area  Is  180 
degrees.  If  the  header  or  footer  area  Is  composite,  the  layout  paths  In  the  lowest 
frames  are  180  degrees; 

d)  H/F  layout  82.  in  this  case,  the  layout  path  in  the  header  and  footer  area  Is  270 
degrees.  If  the  header  or  footer  area  is  composite,  the  layout  paths  in  the  lowest 
frames  are  180  degrees. 


Page  layout  type  is  determined  by  a  combination  of  the  body  layout  type  and  the  H/F  layout  type.  Any 
combination  is  pemiitted.  However,  it  Is  Intended  that  all  applications  which  use  this  profile  shall 
support  the  combinatbns  of  body  layout  A  and  H/F  layout  A1  and  A2,  whereas  support  for  other 
combinations  may  be  specified  as  optional. 

NOTE  14  -  The  combinations  of  body  layout  A  and  H/F  layout  A1,  B  and  A1,  C  and  A1,  and  C  and  81  are 
equivalent  to  page  layouts  A.  B.  C  and  D  in  FOD26  respectively. 

The  header  and  footer  of  H/F  layout  A1  or  A2  are  laid  out  above  and  below  the  body  area.  Figure  1 
illustrates  this  case,  and  figure2  illustrates  H/F  layout  type  A1  and  A2  corresponding  to  this  case. 
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he  header  and  footer  of  H/F  layout  B1  or  B2  are  laid  out  to  the  right  and  left  of  the  twdy  area.  Figure 
illustrates  this  case,  and  figure  4  illustrates  H/F  layout  type  B1  and  82  corresponding  to  this  case. 


N»acuatr  Ar«a 

H/F    layout.   A-1  X 

H/  F    1 ayout  A2 

C270  deai^eeeO 

CO  oec'eeeD 

fc)Ody 
I ayout  C 


C1BO  deorees^ 


body 

I ayout  A 
C270  eieoi-ees3 


body 
I ayout  B 
CO  deareee^ 


H/F    layout  Ai 
C270  degrees^ 


H/  F    I  ayout  A2 
C □  degreee^ 


<ey  : 


I nd I cates 

a  layout 

path  difectior 


igure  1  —  Body  layout  types  A,  B  and  C  with  header  and  footer  above  and  below  the  body  area 


CH/F  layotJt  AH;) 


layout 

— 

►  CP 

|path 

layout 
path 


layout 
path 


Key : 

CP  =  character  path 
LP  =   line  progression 


Header Area  or  Foote'Area 
C^f  layout  A25 


layout  path 


layout 

^  CP 

4  path 

-igure  2  —  Header  and  footer  frame  layouts  corresponding  to  Figure  1 
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Area 


HFB1 


HFB2 


-|  SodvArea 


body 
layout  C 


C  180  dagrMie} 

body 

layout  8 

CO  degrMs} 

body 

layout  A 

C270  dagroasD 

HFB1 


HFB2 


Key ; 

HFB1  =  H/F  layout  B1  CISO  degrees^ 
HFB2  =  H/F  layout  B2  C270  degrees) 


Figure  3 
area 


Body  layout  types  A,  B  and  C  with  header  and  footer  to  the  right  and  left  of  the  bo6y 


CH/F  fayotrt.  gi> 


leyout  path 


layout  path 


LP 


CP 


layout  path 


layout 
oath 


Key: 

CP  =  character  path 
LP  =  line  progression 


Figure  4  —  Header  and  footer  frame  layouts  corresponding  to  Figure  3 
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6.3.5  Body  area  characteristics 


6.3.5.1  General  characteristics 

The  body  area  is  the  area  within  a  page  where  the  main  matter  of  the  document,  that  is  the  'body'  part 
of  the  document,  is  laid  out.  The  layout  path  specified  in  the  body  area  determines  the  body  layout 
type  being  used. 

The  body  area  may  consist  of  a  single  frame  into  which  the  content  is  directly  laid  out.  In  this  case,  the 
body  area  is  represented  by  a  BasicBody  frame. 

Alternatively,  the  body  area  may  be  subdivided  into  different  rectangular  areas  to  provide  for  different 
layout  requirements.  In  this  case,  the  body  frame  is  represented  by  a  VariableCompositeBody  or 
FixedCompositeBody  frame. 

The  subordinate  areas  within  a  VariableCompositeBody  frame  are  represented  by  variably  positioned 
frames.  Thus  the  subordinate  areas  are  not  pre  determined  and  are  automatically  adjusted  during  the 
layout  process  to  accommodate  the  content  that  is  allocated  to  them. 

When  a  FixedCompositeBody  frame  is  used,  the  subordinate  areas  are  represented  by  fixed  positioned 
frames,  and  hence  the  body  area  layout  can  be  precisely  specified. 

However,  in  order  to  provide  boih  areas  whose  layout  is  fixed  and  areas  whose  layout  is  variable  within 
a  single  body  area,  it  is  possible  to  specify  one  or  more  VariableCompositeBody  frames  as 
subordinates  to  a  FixedCompositeBody  frame.  In  this  case,  the  layout  paths  for  each  of  the 
VariableCompositeBody  frames  may  or  may  not  be  the  same.  This  allows,  for  example,  text  belonging 
to  different  languages  to  be  laid  out  on  the  same  page. 


6.3.5.2  BasicBody 

BasicBody  is  a  constituent  constraint  which  defines  a  lowest  level  frame  which  represents  a  body  area 
into  which  content  is  directly  laid  out. 

The  position  and  dimensions  of  this  frame  are  fixed.  The  layout  path  specified  depends  upon  the  body 
layout  type  being  used  (see  6.3.4.5). 


6.3.5.3  VariableCompositeBody 

VariableCompositeBody  is  a  constituent  constraint  that  defines  a  composite  frame  which  represents 
either  the  entire  body  area  or  a  part  of  it,  and  which  contains  one  or  more  subordinate  variably 
positioned  frames.  A  VariableCompositeBody  frame  has  a  fixed  position  and  fixed  dimensions.  The 
layout  path  specified  for  this  frame  depends  upon  the  layout  type  used  (see  6.3.1). 

The  immediate  subordinates  of  this  frame  consist  of  an  arbitrary  ordered  sequence  of  one  or  more 
frames  of  the  following  constituent  constraints: 

—  BasicFloat; 

—  SnakingColumns; 

—  SynchronizedColumns; 
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—  CompositeFloat; 

—  CompositeFixture  Variable; 

—  TableArea; 

—  Footnote  Area; 

—  ArrangedContentVariable; 

—  SourcedContentVariable. 

The  subordinate  frames  are  all  variably  positioned  and  have  variable  dimensions  except  for 
ArrangedContentVariable  frames.  Thus  the  relative  positions  of  these  frames  in  the  body  area  may 
vary  and  depend  upon  the  positions  of  other  frames  {if  any)  that  are  placed  in  the  same 
VariableCpmpositeBody  frame. 

The  layout  path  for  VariableCompositeBody  frarnes  may  be  specified  as  270.  0  or  180  degrees.  This 
determines  the  body  layout  type  used  in  the  case  where  VariableCompositeBody  represents  the  entire 
body  area  (see  6.3.4.5). 

All  immediate  subordinate  frames  are  laid  out  along  the  layout  path  specified  (in  'normal*  positioning  fill 
order).  FootnoteArea  frames  are  laid  out  in  the  same  direction  as  the  body  area  layout  path,  but 
reverse  fill  order  is  used. 

Also  frames  are  constrained  to  have  the  same  layout  path  as  the  VariableCompositeBody  frame  to 
which  they  are  subordinate.  However,  exceptions  to  this  rule  are  frames  of  the  types 
CompositeFixtureVariable,  CompositeFloat,  SnakingColumns  and  SourcedContentVariable  (see 
appropriate  subclause  below). 

Figures  5,  6  and  7  provide  illustrations  of  the  layout  of  frames  within  a  VariableCompositeBody  frame 
for  the  various  body  layout  types. 

A  choice  of  subordinate  frames  of  the  types  listed  above  may  be  specified  for  a 
VariableCompositeBody  frame.  Different  frame  types  may  be  selected  using  various  layout  directives 
(see  6.4)  and,  therefore,  the  layout  characteristics  of  the  body  areas  within  a  page  set  may  change 
from  page  to  page  within  a  page  set. 


6.3.5.4  FixedCompositeBody 

FixedCompositeBodv  is  a  constituent  constraint  that  defines  a  composite  frame  which  represents  the 
body  area  and  which  contains  one  or  nrwre  subordinate  frames  that  are  fixed  in  position.  The  position 
and  dimensions  of  this  frame  are  fixed. 

The  immediate  subordinates  of  frames  of  this  type  consist  of  an  arbitrary  ordered  sequence  of  one  or 
more  frames  of  the  following  constituent  constraints: 

—  BasicFixture; 

—  ColumnFixed; 

—  CompositeCommon; 

—  CompositeFixtureFixed; 
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Figure  5  —  Example  of  body  area  layout  for  txxfy  layout  type  A 

—  ArrangedContentFixed: 
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Figure  6  —  Example  of  body  area  layout  for  body  layout  type  B 
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39 


—  SourcedContentFixed; 
. —  VariableCompositeBody. 
The  subordinate  frames  may  overlap  without  restriction. 

The  layout  path  for  FixedCompositeBody  frames  may  be  specified  as  270.  0  or  180  degrees.  This 
determines  the  body  layout  type  used  (see  6.3.4.5).  The  layout  path  specified  does  not  affect  the 
positioning  of  frames,  but  it  may  affect  their  dimensions  since  some  of  the  frames  listed  above  have 
variable  dimensions  in  a  particular  direction. 

Also  frames  are  constrained  to  have  the  same  layout  path  as  the  FixedCompositeBody  frame  to  which 
they  are  subordinate.  However,  exceptions  to  this  rule  are  frames  of  the  types  VariableCompositeBody. 
CompositeFixtureFixed  and  SourcedContentFixed  (see  appropriate  subclause  below). 

A  choice  of  sutx)rdinate  frames  of  the  types  listed  at>ove  may  be  specified  for  a  FixedCompositeBody 
frame.  Different  frame  types  may  be  selected  using  various  layout  directives  (see  6.4).  and.  therefore, 
the  layout  characteristics  of  the  tx)dy  areas  within  a  page  set  may  change  from  page  to  page  within  a 
page  set. 


6.3.5.5  BasicFloat 

BasicFloat  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  is  used  to  represent  a  single 
column  area  within  a  tx>dy  area. 

This  is  a  variably  positioned  frame  which  may  be  specified  as  a  subordinate  to  frames  of  the  types 
VariableCompositeBody,  CompositeColumn Variable,  CompositeColumnFixed,  CompositeFixtureVariable 
and  CompositeFixtureFixed. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  body  area  is  fixed  or 
defaults  to  the  maximum  value  allowed  within  the  tx)dy  area. 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  body  area  is  specified  as 
'Rule-B'.  This  dimension  is  therefore  automatically  adjusted  during  the  layout  process  to  be  the 
minimum  required  to  contain  all  the  content  allocated  to  the  frame. 

The  layout  path  specified  for  this  frame  is  the  same  as  that  specified  for  its  superior  frame.  Content 
shall  only  be  laid  out  in  this  frame  in  the  direction  of  the  layout  path  specified. 


6.3.5.6  SnaklngColumns 

SnakingColumns  is  a  constituent  constraint  that  defines  a  composite  frame  that  represents  a  snaking 
columns  area  within  a  body  area.  A  snaking  columns  area  is  typically  used  for  the  layout  of  one  or 
more  columns  of  content  in  which  the  content  is  allowed  to  flow  freely  from  one  column  to  the  next. 
Examples  are  shown  in  figure  8  and  figure  9. 

This  is  a  variably  positioned  frame  which  may  only  be  specified  as  a  sutxjrdinate  to  a 
VariableCompositeBody  frame. 

Its  immediate  subordinates  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  frames  of  the 
following  constituent  constraints: 
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Figure  8  —  Example  of  the  layout  of  a  snaking  columns  frame 
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Figure  9  —  Another  example  of  the  layout  of  a  snaking  columns  frame 


—  Column  Variable; 

—  ComposlteColumn  Variable; 

—  ArrangedContentVariable; 

—  SourcedContentVariable. 

The  dimension  of  the  SnakingColumns  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  lx)dy 
area  is  fixed  or  defaults  to  the  maximum  value  allowed  within  the  body  area. 
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The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  body  area  is  specified  as 
'Rule-B'.  This  dimension  is  therefore  automatically  adjusted  to  accommodate  the  subordinate  frames 
which  are  laid  out  in  it. 

The  layout  path  for  a  SnakingColumns  frame  may  be  specified  as  0  or  180  degrees  in  the  case  of  body 
layout  A,  90  or  270  degrees  in  the  case  of  body  layout  B,  and  270  degrees  in  the  case  of  body  layout 
C. 

The  attribute  "balance"  may  be  specified  for  a  SnakingColumns  frame  to  indicate  that  two  or  more  of 
the  subordinate  ColumnVariable  frames  are  to  be  approximately  equal  in  length  in  the  vertical 
dimension  in  the  case  of  body  layout  A  and  approximately  equal  in  length  in  the  horizontal  dimension  in 
the  cases  of  body  layouts  B  and  C.  Note  that  "approximately  equal"  in  the  context  of  the  "balance" 
attribute  means  that  the  leading  edges  of  the  layout  objects  being  balanced  are  aligned  as  closely  as 
possible  to  a  line  orthogonal  to  the  layout  path  for  the  objects. 


6.3.5.7  SynchronizedColumns 

SynchronizedColumns  is  a  constituent  constraint  that  defines  a  composite  frame  that  represents  a 
synchronized  columns  area  within  a  body  area.  A  synchronized  columns  area  is  typically  used  to 
represent  one  or  more  columns  of  content  such  that  the  content  laid  out  in  each  column  belongs  to 
different  layout  streams.  Thus  content  laid  out  in  one  column  is  not  allowed  to  flow  into  the  next 
column. 

This  type  of  column  layout  is  typically  used  when  it  is  required  to  layout  separate  amounts  of  content  in 
parallel  with  one  another  such  that  they  are  aligned.  Examples  are  the  synchronized  layout  of  content 
belonging  to  different  languages  and  the  layout  of  a  figure  in  parallel  with  some  text.  An  example  is 
shown  in  figure  10. 

With  regard  to  positioning  and  dimensioning,  SynchronizedColumns  frames  have  the  same 
characteristics  as  SnakingColumns  frames. 

The  immediate  subordinates  of  a  SynchronizedColumns  frame  consist  of  an  arbitrary  ordered  sequence 
of  one  or  more  of  the  following  constituent  constraints: 

—  ColumnFixed; 

—  CompositeColumnFixed; 

—  ArrangedContentFixed; 

—  SourcedContentFixed. 

The  layout  path  for  a  SynchronizedColumns  frame  is  270  degrees  for  body  layout  A,  0  degrees  for 
body  layout  B  and  180  degrees  for  body  layout  C. 


6.3.5.8  CompositeFloat 

CompositeFloat  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  which 
is  used  for  the  side  by  side  layout  of  complex  objects  such  as  figures,  forms  or  tables  and  simple 
columns  of  text. 

This  is  a  variably  positioned  frame  which  may  be  specified  as  a  subordinate  to  a 
VariableCompositeBody,  CompositeColumnVariable  or  CompositeColumnFixed  frame. 
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Figure  10  —  Example  of  the  layout  of  a  synchronized  column 


The  dimension  of  a  CompositeFloat  frame  in  the  direction  orthogonal  to  the  layout  path  of  its  superior 
frame  is  fixed  or  defaults  to  the  maximum  value  allowed. 

The  dimension  of  the  frame  in  the  direction  parallel  to  the  layout  path  is  specified  by  'Rule-A*.  Thus  the 
dimension  in  this  direction  is  determined  by  the  dimension  in  the  same  direction  of  the  first  frame  that  is 
laid  out  in  the  CompositeFloat  frame. 

The  immediate  sutwrdinates  of  this  frame  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  of 
the  following  constituent  constraints: 

—  BasicColumn; 

—  CompositeFixtureVariable; 

—  Table  Area; 

—  ArrangedContentVariable; 

—  SourcedContentVariable. 

The  layout  path  for  a  CompositeFloat  may  be  specified  as  0  or  180  degrees  in  the  case  of  body  layout 
A  and  as  90  or  270  degrees  in  the  case  of  body  layouts  B  and  C. 

A  typical  example  of  the  use  of  this  constituent  is  a  form  or  an  illustration  with  character  content  flowing 
to  its  side  as  shown  in  figure  1 1 . 
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Figure  11     Example  of  a  CompositeFloat  frame 


6.3.5.9  CompositeFixtureVariable 

CompositeFixtu  re  Variable  is  a  constituent  constraint  that  defines  a  composite  frame  used  to  specify  an 
area  whicti  is  used  to  layout  an  illustration,  such  as  a  figure  or  form,  with  which  is  associated  some 
descriptive  text  and  a  caption.  Hence,  the  prime  purpose  of  this  frame  is  to  layout  logical  constituent 
constraints  of  the  type  Figure. 

This  is  a  variably  positioned  frame  which  may  be  specified  as  a  subordinate  to  a 
VariableCompositeBody,  CompositeColumnVariable  or  CompositeColumnFixed  frame. 

The  dimension  of  a  CompositeFixtureVariable  frame  in  the  direction  orthogonal  to  the  layout  path  of  the 
superior  frame  is  fixed,  specified  as  'Rule-B"  or  defaults  to  the  maximum  allowed.  In  the  direction 
parallel  to  the  layout  path  of  the  superior  frame,  the  dimension  may  be  fixed  or  specified  as  'Rule-B'. 

The  immediate  sutx)rdinates  of  this  frame  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  of 
the  following  constituent  constraints: 

—  BasicFtoat; 


—  CompositeArtwork; 

—  FormArea; 

—  Footnote  Area. 


NOTE  15  -  The  layout  path  of  a  CompositeFixtureVariable  frame  may  be  set  to  0,  180  or  270  degrees  in  the 
case  of  body  layout  A,  to  0.  90  or  270  degrees  in  the  case  of  body  layout  B  and  1 80  or  270  degrees  in  the 
case  of  body  layout  C. 


All  subordinate  frames  are  laid  out  in  'normal"  positioning  fill  order  with  the  exception  of  FootnoteArea 
frames  which  are  laid  out  in  reverse'  fill  order. 
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Examples  of  the  layout  of  ComposlteFixtureVariable  frames  are  shown  in  figure  12. 


6.3.5.10  CompositeFixtureFixed 

CompositeFixtureFixed  is  a  constituent  constraint  that  defines  a  composite  frame  which  has  the  same 
characteristics  as  that  of  a  CompositeFixtureVariable  frame,  except  for  the  positioning  and  dimensions. 


This  frame  may  be  specified  as  a  subordinate  to  a  FixedCompositeBody  frame. 


6.3.5.11  CompositeArtwork 

CompositeArtwork  is  a  constituent  constraint  that  defines  a  composite  frame  that  represents  an  area 
that  contains  an  illustration  such  as  a  figure  or  diagram.  It  is  used  for  laying  out  logical  constituents  of 
the  type  Artwork  which  are  subordinate  to  logical  constituent  constraints  of  the  type  Figure. 

j  This  is  a  variably  positioned  frame  that  may  be  specified  as  a  sutx>rdinate  to  a 
CompositeFixtureVariable  or  CompositeFixtureFixed  frame. 

}  The  dimensions  of  this  frame  in  the  directions  orthogonal  and  parallel  to  the  layout  path  of  the  superior 
j  frame  may  be  independently  either  fixed  or  specified  as  Rule-B'. 

1  The  immediate  sut)ordinates  of  a  CompositeArtwork  frame  consist  of  a  secjuence  of  one  or  more  towest 
jj  level  frames  of  the  type  BasicFixture  which  contain  character,  raster  graphics  or  geometric  graphics 
I  content.  BasicFixture  frames  may  overlap  to  allow  composite  images  to  be  formed. 

The  layout  path  of  a  CompositeArtwork  frame  Is  set  to  be  the  same  as  that  of  its  superior  frame  (see 
note). 

I       NOTE  16  -  Subject  to  this  restriction,  this  means  that  the  layout  path  of  a  CompositeArtwork  frame  may  be  set 
jl       to  0,  180  or  270  degrees  in  the  case  of  body  layout  A.  to  0,  90  or  270  degrees  in  the  case  of  body  layout  B 
i       and  180  or  270  degrees  in  the  case  of  body  layout  C. 


6.3.5.12  BasicFixture 

BasicFixture  is  a  constituent  constraint  that  defines  a  lowest  level  frame  which  specifies  an  area  for 
laying  out  content  within  FixedCompositeBody  and  CompositeArtwork. 

This  frame  has  a  fixed  position  within  its  superior  frame.  The  dimensions  of  this  frame  in  the  directions 
orthogonal  and  parallel  to  the  layout  path  of  the  superior  frame  may  be  independently  either  fixed  or 
specified  as  'Rule-B'. 

If  the  superior  frame  of  a  BasicFixture  frame  is  FixedCompositeBody,  the  layout  path  of  the 
BasicFixture  frame  is  set  to  be  the  same  as  that  of  its  superior  frame. 

If  the  superior  frame  of  a  BasicFixture  frame  is  CompositeArtwork,  the  layout  path  of  the  BasicFixture 
frame  is  restricted  as  follows: 
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Figure  12  —  Example  of  a  CompositeFixture Variable  frame 
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—  if  the  layout  path  of  the  superbr  frame  is  set  to  270  degrees,  the  layout  path  of 
BasicFixture  may  be  set  to  270  or  180  degrees; 

—  if  the  layout  path  of  the  superior  frame  is  set  to  0  degrees,  the  layout  path  of 
BasicFixture  may  be  set  to  0  or  270  degrees; 

—  if  the  layout  path  of  the  superior  frame  is  set  to  180  degrees,  the  layout  path  of 
BasicFixture  may  be  set  to  180  or  270  degrees. 


6.3.5.13  FormArea 

FormArea  is  a  constituent  constraint  that  defines  a  composite  frame  which  represents  a  fixed 
dimensioned  area  reserved  for  laying  out  an  illustration  consisting  of  a  form. 

This  area  is  divided  into  one  or  more  'simple'  and  'composite'  areas.  A  simple  area  is  one  In  which 
content  is  directly  laid  out.  A  'composite'  area  is  an  area  which  is  further  divided  into  one  or  more 
simple  and  composite  areas. 

This  is  a  variably  positioned  frame  that  may  be  specified  as  a  subordinate  to  a 
CompositeFixtureVariable  or  CompositeFixtureFixed  frame. 

The  dimensions  of  this  frame  are  fixed  in  both  directions. 

The  immediate  subordinates  of  a  FormArea  frame  consists  of  an  arbitrary  ordered  sequence  of  one  or 
more  fixed  positioned  frames  of  the  following  constituent  constraints: 

—  FormEntryArea; 

—  EntryGroupArea; 

—  ArrangedContentFixed. 

Frames  of  the  type  FormEntryArea  and  ArrangedContentFixed  represent  simple*  areas  in  a  form  as 
described  above.  EntryGroupArea  frames  represent  'composite'  areas. 

The  layout  path  of  a  FormArea  frame  defaults  to  270  degrees  and  does  not  affect  the  layout  of 
subordinate  frames. 

An  example  of  the  layout  of  a  form  is  shown  In  Figure  13. 


6.3.5.14  EntryGroupArea 

EntryGroupArea  is  a  constituent  constraint  that  represents  a  composite  area  within  a  FormArea  frame. 
The  positions  and  dimensions  of  this  frame  are  fixed  in  both  directions.  The  layout  path  of  this  frame 
defaults  to  270  degrees. 

The  immediate  subordinates  of  this  frame  consist  of  an  arbitrary  ordered  sequence  of  one  or  more  fixed 
positioned  frames  of  the  type  FonnEntryArea. 
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6.3.5.15  FormEntryArea 

FormEntryArea  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  specifies  an  area  for 
laying  out  content  within  a  FormArea  frame.  This  frame  may  contain  character,  raster  graphics  or 
geometric  graphics  content. 

The  position  and  dimensions  of  this  frame  are  fixed.  Its  layout  path  is  270  degrees  regardless  of  the 
page  layout  type. 


6.3.5.16  BasicColumn 

BasicColumn  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  specifies  an  area  for 
laying  out  content  in  the  form  of  a  column  within  a  CompositeFloat  frame.  This  frame  has  a  variable 
position  within  its  superior  frame. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of  its  superior  frame  may  be 
fixed  or  specified  as  'Rule-B'.  Its  dimension  in  the  direction  parallel  to  the  layout  path  of  the  superior 
frame  may  be  fixed,  specified  as  "Rule-B"  or  defaulted  to  its  maximum  size.  Thus  the  dimensions  of 
this  frame  may  be  allowed  to  be  automatically  adjusted  so  that  it  contains  all  the  content  allocated  to  it 

The  layout  path  specified  for  this  frame  is  specified  as  270  degrees  in  the  case  of  body  layout  A,  0 
degrees  in  the  case  of  body  layout  B  and  180  degrees  in  the  case  of  body  layout  C. 
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6.3.5.17  ColumnVariable 

ColumnVariable  is  a  constituent  constraint  that  defines  a  lowest  level  frame  tfiat  is  used  to  represents  a 
column  of  content  witfiin  a  SnakingColumns  frame.  This  is  a  frame  which  is  variably  positioned. 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior  SnakingColumns 
frame  (that  is,  the  column  width)  is  fixed.  The  dimensions  of  different  instances  of  ColumnVariable 

I  frames  within  a  given  SnakingColumns  frame  may  differ  to  allow  columns  of  different  widths  to  be 

I  specified. 

I  The  dimension  in  the  direction  orthogonal  to  the  layout  path  of  the  superior  frame  (that  is,  the  column 
j  length)  may  be  specified  as  'Rule-B'  or  'maximum-size'. 

I 

The  layout  path  for  ColumnVariable  frames  is  270  degrees  in  the  case  of  body  layout  A,  0  degrees  In 
body  layout  B  and  180  degrees  in  body  layout  C. 

All  ColumnVariable  frames  subordinate  to  the  same  SnakingColumns  frame  shall  have  the  same 
category  name;  different  names  may  be  used  for  ColumnVariable  frames  laid  out  in  different 
!  SnakingColumns  frames. 


6.3.5.18  CompositeColumnVariable 

CompositeColumnVariable  is  a  constituent  constraint  that  defines  a  composite  frame  which  specifies  an 
area  representing  a  column  within  a  SnakingColumns  frame.  The  column  is  subdivided  into  different 
areas  to  allow  different  layout  requirements  to  be  achieved.  For  example,  this  frame  can  be  used  to 
represent  a  column  containing  a  table  and  a  complex  diagram  which  is  embedded  in  a  stream  of 
character  content.  This  is  a  frame  which  is  variably  positioned. 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior  SnakingColumns 
frame  (that  is,  the  column  width)  is  fixed.  The  dimensions  of  different  instances  of 
CompositeColumnVariable  frames  within  a  given  SnakingColumns  frame  may  differ  to  allow  columns  of 
different  widths  to  be  specified. 

The  dimension  in  the  direction  orthogonal  to  the  layout  path  of  the  superior  frame  (that  is,  the  column 
length)  may  be  specified  as  'Rule-B'  or  'maximum-size'. 

The  immediate  subordinates  of  this  frame  consist  of  an  arbitrary  ordered  sequence  of  frames  of  the 
following  constituent  constraints; 

—  BasicFloat; 

—  CompositeFloat; 

—  CompositeFixtureVariable; 

—  Table  Area; 

—  Footnote  Area; 

—  ArrangedContentVariable; 

—  SourcedContentVariable. 
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The  layout  path  for  CompositeColumnVariable  frames  is  270  degrees  in  the  case  of  body  layout  A,  0 
degrees  in  body  layout  B  and  180  degrees  in  body  layout  C. 

All  subordinate  frames  are  laid  out  in  "normal'  positioning  fill  order  except  FootnoteArea  which  is  laid  out 
in  "reverse'  fill  order. 


6.3.5.19  ColumnFixed 

ColumnFixed  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  is  used  to  represent  a 
column  of  content  within  a  FixedCompositeBody  or  SynchronizedColumns  frame.  This  is  a  frame  which 
has  a  fixed  position. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  superior  frame  (that  is, 
the  column  width)  may  be  fixed  or  specified  as  maximum  size'  (see  note).  This  dimension  may  differ 
for  different  instances  of  ColumnFixed  frames  within  a  given  SynchronizedColumns  frame  to  allow 
columns  of  different  widths  to  be  specified.  However,  the  widths  shall  be  specified  such  that  the 
columns  do  not  overlap. 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior  frame  (that  is,  the 
column  length)  may  be  specified  as  "Rule-B'  or  maximum-size'  in  the  cases  of  body  layouts  A  and  B. 
In  the  case  of  body  layout  C,  this  dimension  shall  only  be  specified  as  'maximum-size'. 

The  ColumnFixed  frames  subordinate  to  a  given  SynchronizedColumns  frame  must  have  different 
category  names. 

The  layout  path  for  ColumnFixed  frames  shall  be  equal  to  the  layout  path  of  the  superior 
SynchronizedColumns  frame. 

The  content  laid  out  in  different  ColumnFixed  frames  within  the  same  SynchronizedColumns  frame  may 
be  specified  as  synchronized'  by  using  the  attribute  "synchronization". 

NOTE  17  -  The  value  'maximum  size'  shall  only  be  specified  for  the  last  ColumnFixed  frame  laid  out  in  a 
SynchronizedColumns  frame  to  prevent  overlapping  of  the  frames.  That  is,  for  a  page  coordinate  system  with 
its  reference  point  in  the  upper  left  corner,  only  the  right  most  ColumnFixed  frame  shall  specify  maximum  size' 
without  the  risk  of  overlapping  frames. 


6.3.5.20  CompositeCoiumnFixed 

CompositeColumnFixed  is  a  constituent  constraint  that  defines  a  composite  frame  which  specifies  an 
area  representing  a  column  within  a  SynchronizedColumns  frame.  The  column  is  subdivided  into 
different  areas  to  allow  different  layout  requirements  to  be  achieved. 

The  characteristics  of  this  frame  are  the  same  as  those  of  CompositeColumnVariable  frames,  except 
that  this  frame  has  a  fixed  position,  and  its  dimensions  are  the  same  as  for  ColumnFixed  frames. 


6.3.5.21  FootnoteArea 

FootnoteArea  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  is  used  to  represent  an 
area  reserved  for  the  layout  of  footnotes.  Footnotes  may  be  placed  in  body  areas  and  also  in  columns  i 
and  areas  reserved  for  illustrations  within  body  areas.  i 

» 

This  frame  may  be  specified  as  a  subordinate  to  frames  of  the  constituent  constraints: 
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—  VahableCompositeBody; 

—  CompositeColumnVariable; 

—  CompositeColumn  Fixed; 

—  CompositeFixtureVariable; 

—  CompositeFixtureFixed. 

Frames  of  this  type  are  variably  positioned  with  a  positioning  fill  order  specified  as  'reverse'.  Therefore, 
this  frame  is  positioned  adjacent  to  the  leading  edge  of  its  superior  frame. 

The  dimension  of  FootnoteArea  frames  in  the  direction  orthogonal  to  the  layout  path  of  its  superior 
frame  is  fixed  or  specified  as  'maximum  size'.  In  the  direction  of  the  layout  path,  the  dimension  is 
specified  by  'Rule-B'  which  means  that  this  dimension  is  automatically  adjusted  to  contain  all  the 
content  that  is  allocated  to  it. 

The  layout  path  for  FootnoteArea  frames  is  the  same  as  that  specified  for  the  superior  frame. 

The  content  that  may  be  laid  out  in  this  frame  is  limited  to  the  content  that  is  associated  with  basic 
logical  objects  which  are  directly  or  indirectly  subordinate  to  the  composite  logical  object  FootnoteBody. 
To  achieve  this,  the  "permitted  categories"  attribute  of  this  frame  shall  specify  the  same  category  name 
required  on  the  basic  logical  objects  for  footnotes  (see  6.2.3.9.4  and  6.2.3.9.5). 


6.3.5.22  CompositeCommon 

CompositeCommon  is  a  constituent  constraint  that  defines  a  composite  frame  which  specifies  an  area 
within  the  body  area  that  is  to  contain  common  content.  This  area  may  be  subdivided  so  that  different 
types  of  common  content  may  be  laid  out. 

This  Is  a  frame  which  has  fixed  positions  and  dimensions.  It  may  be  specified  as  a  subordinate  to  a 
FixedCompositeBody  frame. 

The  sutx)rdinates  of  a  CompositeCommon  frame  may  consist  of  either: 

a)  any  number  and  combination  of  variably  positioned  frames  of  the  types 
SourcedContentVariable  and  ArrangedContentVariable,  or; 

b)  any  number  and  combination  of  fixed  positioned  frames  of  the  types 
SourcedContentFixed  and  ArrangedContentFixed. 

In  case  b),  the  sutwrdinate  frames  may  overlap  without  restriction. 

The  layout  path  of  a  CompositeCommon  frame  is  270,  0  and  180  degrees  in  the  cases  of  tx)dy  layouts 
A,  B  and  C  respectively. 


6.3.5.23  Constituents  used  for  laying  out  tables 

This  subclause  defines  the  constituents  used  to  support  the  layout  of  tables.  An  overview  of  the  layout 
features  pertaining  to  tables  is  given  in  6.3.5.22.1  and  the  subsequent  subclauses  define  the  individual 
constituents  provided. 
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6.3.5.23.1  Overview 

A  table  consists  of  three  main  areas: 

—  a  single  optional  header  area  which  is  placed  at  the  top  of  the  table; 

—  a  single  optional  table  label  area  which  is  placed  immediately  below  the  header  area; 

—  one  or  more  row  areas,  which  are  placed  in  sequence  below  the  header  area  and  table 
label  area. 

The  table  header  area  is  typically  used  to  contain  a  title  or  caption  that  describes  the  purpose  of  the 
table.  It  is  an  area  which  is  subdivided  into  one  or  more  areas,  each  of  which  contains  common 
content  derived  from  the  logical  structure  using  the  logical  source'  mechanism. 

The  table  label  area  Is  typically  used  to  contain  the  labels  which  relate  to  the  columns  In  the  table.  The 
row  areas  form  the  main  body  of  the  table  and  are  used  to  layout  the  information  that  t)elongs  to  the 
table.  These  areas  may  be  "simple"  or  composite'  as  described  below. 

An  example  of  a  simple  table  is  shown  in  figure  14.  In  this  example,  the  table  label  and  each  row 
consist  of  a  sequence  of  areas  called  "cells"  which  are  laid  out  horizontally  across  the  table  area. 
These  are  examples  of  'simple'  table  label  and  row  areas. 


Table  header  area 

Table   label  area 

Row  area 

Row  area 

Row  area 

Row  area 

Row  area 


Figure  14  —  Example  of  a  simple  table 


An  example  of  a  rrwre  complex  table  is  shown  in  figure  15  which  illustrates  the  use  of  'composite'  table 
labels  and  row  areas.  A  composite  table  label  area  consists  of  a  sequence  of  two  or  more  sub-rows, 
each  of  which  is  divided  into  separate  cells.  The  cells  in  each  row  may  or  may  not  be  the  same  size  to 
allow  a  label  to  refer  to  a  single  column  or  several  columns.   The  sequence  of  sub-rows  may  be 
preceded  on  the  left  by  a  single  cell  which,  for  example,  can  be  used  to  contain  a  title  which  refers  to 
the  group  of  sub-rows. 
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Tab  I e  header  area 


Figure  15  —  Example  of  a  complex  table 
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Composite  row  areas  have  the  same  general  structure  as  composite  table  label  areas.  By  mixing 
together  difterent  combination  of  simple'  and  composite'  table  label  and  row  areas,  it  is  possible  to 
obtain  a  wide  range  of  different  table  types. 

The  frames  that  are  used  to  represent  table  label  and  row  areas  are  shown  in  figures  16  and  17 
respectively.  The  areas  labelled  as  'cells'  are  intended  to  accommodate  content  belonging  to  a  single 
content  type.  The  frames  which  represent  the  'cells'  are  fixed  in  position  and  have  a  fixed  horizontal 
dimension.  However,  the  vertical  dimension  of  a  cell  may  be  specified  as  variable,  so  that  this 
dimension  is  automatically  adjusted  during  the  layout  process  to  accommodate  all  the  content  allocated 
to  it. 


In  the  case  of  a  composite  table  label  or  row,  the  containing  frame  (that  is,  the  LabelComponent  or 
SubRow  frame  respectively)  also  has  a  dimension  which  is  variable  in  the  vertical  direction.  Thus  the 
dimension  of  this  frame  may  be  automatically  adjusted  during  the  layout  process  so  that  it  is  large 
enough  to  accomnrodate  the  largest  cell  in  that  row. 

Also,  the  containing  frames  (that  is,  the  CompositeTableLabel,  TableLabel,  SubRowGroup  and  SubRow 
frames)  may  all  be  specified  as  having  a  variable  vertical  dimension,  and,  therefore,  the  vertical 
dimension  of  each  table  label  and  row  area  may  be  automatically  adjusted  to  take  into  account  all  the 
information  that  is  to  be  laid  out  in  these  areas. 

The  frames  which  specifies  the  complete  table  area  (that  Is,  the  TableArea  frame),  which  is  not  shown 
in  the  figures,  also  may  have  a  variable  vertical  dimension. 

The  mechanism  by  which  content  is  allocated  to  the  cells'  in  a  table  is  described  in  6.4.1.3.8. 
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6.3.5.23.2  TableArea 


TableArea  is  a  constituent  constraint  that  defines  a  composite  frame  ttiat  is  used  to  specify  an  area 
reserved  for  the  layout  of  a  table.  This  constituent  constraint  may  be  specified  as  a  subordinate  to  the 
following  constituent  constraints: 

—  VariableCompositeBody; 

—  Composite  Float; 

—  ComposileColumn  Variable; 

—  CompositeColumnFixed. 

This  is  a  frame  that  has  a  variable  position.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed  or 
specified  as  Rule-B".  Its  layout  path  is  specified  as  270  degrees. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  an  optional  TableHeader,  followed 
by  an  optional  TableLabel,  which  is  followed  by  a  sequence  of  one  or  more  constituent  constraints  of 
the  types  RowArea  and  an  optional  TableLabel. 


6.3.5.23.3  TableHeader 

TableHeader  is  a  constituent  constraint  that  specifies  a  composite  frame  that  specifies  an  area  within  a 
TableArea  frame  that  is  typically  used  to  present  the  header  infomiation  associated  with  a  table. 

This  is  a  frame  whose  position  is  variable.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed  or 
specified  as  'Rule-B'. 

The  immediate  sutx)rdinates  of  this  constituent  constraint  consist  of  a  sequence  of  constituent 
constraints  of  the  type  SourcedContentFixed.  Hence,  the  content  laid  out  in  a  TableHeader  frame  is 
derived  from  logical  constituent  constraints  of  the  type  CommonContent. 


6.3.5.23.4  TableLabel 

TableLabel  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  within  a 
TableArea  frame  that  is  used  for  laying  out  labelling  information  relating  to  the  columns  of  information  in 
the  table. 

This  is  a  frame  whose  position  is  variable  Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed  or 
specified  as  'Rule-B'. 

The  immediate  sutwrdinates  of  this  constituent  constraint  consist  of  either: 

a)  a  sequence  of  one  or  more  constituent  constraints  of  the  type  TableLabelContent,  or; 

b)  a  sequence  of  a  constituent  constraint  of  the  type  TableLabelContent,  and  a  constituent 
constraint  of  the  type  CompositeTableLabel. 
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Figure  16  —  Frames  used  to  represent  table  labels 


6.3.5.23.5  CompositeTableLabei 

CompositeTableLabel  is  a  constituent  constraint  that  defines  a  composite  frame  tfiat  specifies  an  area 
with  a  TableLabel  frame  for  laying  out  a  composite  table  label. 

This  is  a  frame  whose  position  is  fixed.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path  of 
its  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed,  specified  as 
'Rule-B'  or  defaults  to  the  maximum  size  allowed. 

The  Immediate  sut)ordinates  of  this  constituent  constraint  consist  of  a  sequence  of  one  or  more 
constituent  constraints  of  the  type  LabelComponent. 


6.3.5.23.6  LabelComponent 

LabelComponent  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  within 
an  CompositeTableLabel  frame  for  laying  out  a  row  of  labels  within  a  table  header. 

This  is  a  frame  whose  position  is  variable.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed,  specified 
as  *Rule-B'  or  defaults  to  the  maximum  size  allowed. 
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Figure  17  —  Frames  used  to  represent  table  rows 


The  immediate  subordinates  of  this  frame  consist  of  a  sequence  of  constituent  constraints  of  the  type 
TableLabelContent. 


6.3.5.23.7  TableLjibelComent 

TableLabelContent  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  defines  an  area 
within  a  TableLabel  or  LabelComponent  frame  that  is  used  for  laying  out  header  information  that  relates 
to  one  or  more  columns  in  a  XatAe.  Character,  raster  graphics  or  geometric  graphics  content  may  be 
allocated  to  this  frame. 

This  is  a  frame  whose  position  is  fixed.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path  of 
the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed  or  defaults 
to  the  maximum  size  allowed. 

The  content  of  a  frame  of  this  type  is  derived  from  a  logical  constituent  constraint  of  the  type 
CommonContent,  using  the  logical  source  mechanism. 
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6.3.5.23.8  RowArea 


Row  Area  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  within  a 
TableArea  frame  used  for  laying  out  a  row  of  entries  in  a  table. 

This  is  a  frame  whose  position  is  variable.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed  or 
specified  as  Rule-B'. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  either: 

a)  a  sequence  of  one  or  more  constituent  constraints  of  the  type  Cell,  or; 

b)  a  sequence  of  a  single  constituent  constraint  of  the  type  Cell,  and  a  constituent 
constraint  of  the  type  SubRowGroup. 


6.3.5.23.9  SubRowGroup 

SubRowGroup  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  within  a 
RowArea  frame  for  laying  out  a  composite  row  of  entries  in  a  table. 

This  is  a  frame  whose  position  is  fixed.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path  of 
its  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  direction  of  the  layout  path  is 
fixed,  specified  as  Rule-B'  or  defaults  to  the  maximum  size  allowed. 

The  immediate  subordinates  of  this  constituent  constraint  consist  of  a  sequence  of  one  or  more 
constituent  constraints  of  the  type  SubRow. 


6.3.5.23.10  SubRow 

SubRow  is  a  constituent  constraint  that  defines  a  composite  frame  that  specifies  an  area  within  a 
SubRowGroup  frame  for  laying  out  a  sub  row  of  entries  within  a  composite  row  in  a  table. 

This  is  a  frame  whose  position  is  variable.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path 
of  the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed,  specified 
as  Rule-B'  or  defaults  to  the  maximum  size  allowed. 

The  immediate  subordinates  of  this  frame  consist  of  a  sequence  of  constituent  constraints  of  the  type 
Cell. 


6.3.5.23.11  Cell 

Cell  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  specifies  an  area  within  a  RowArea 
or  SubRow  frame  for  laying  out  an  entry  in  a  table. 

This  is  a  frame  whose  fxjsition  is  fixed.  Its  dimension  in  the  direction  orthogonal  to  the  layout  path  of 
the  superior  frame  is  fixed.  Its  dimension  in  the  direction  parallel  to  the  layout  path  is  fixed,  specified 
as  'Rule-B'  or  defaults  to  the  maximum  size  allowed. 

The  content  of  frames  of  this  type  is  derived  from  logical  constituent  constraints  of  the  type 
EntryElement. 
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6.3.6  Header  and  footer  area  characteristics 


6.3.6.1  Generai  characteristics 

The  header  and  footer  areas  may  consist  of  either  basic  areas  or  composite  areas. 

A  basic  header  or  fooler  area  is  an  area  into  which  the  content  is  directly  laid  out.  This  type  of  area  is 
represented  by  a  constituent  constraint  of  the  types  BasicHeader  or  BasicFooter  respectively. 

A  composite  header  or  footer  area  is  an  area  which  is  subdivided  into  separate  sourced  content  and 
arranged  content  areas  to  provide  greater  versatility  with  regard  to  the  layout  of  the  content.   This  type 
of  area  is  represented  by  a  constituent  constraint  of  the  types  CompositeHeader  or  CompositeFooter 
respectively. 

In  the  case  of  basic  header  or  footer  areas,  the  content  allocated  to  these  areas  is  derived  from  the 
common  part  of  the  logical  structure  of  a  document.  In  the  case  of  composite  header  or  footer  areas, 
the  content  may  again  be  derived  from  the  common  part  of  the  logical  structure  of  a  document,  but  the 
content  may  also  be  derived  from  common  content  specified  in  the  generic  layout  structure. 


6.3.6.2  BasicHeader  and  BasicFooter 

BasicHeader  and  BasicFooter  are  constituent  constraints  that  define  lowest  level  franies  that  represent 
areas  within  a  page  that  are  reserved  for  common  content. 

These  types  of  frame  have  fixed  positions  and  dimensions.  The  positioning  of  these  frames  within  a 
page  and  the  layout  paths  that  may  be  specified  for  them  depends  upon  the  H/F  layout  type  used  (see 
6.3.4.5). 

The  content  that  is  laid  out  in  these  frames  is  derived,  using  the  logical  source  mechanism,  from  the 
content  associated  with  the  composite  logical  object  classes  of  the  type  CommonContent. 


6.3.6.3  CompositeHeader  and  CompositeFooter 

CompositeHeader  and  CompositeFooter  are  constituent  constraints  that  define  composite  frames  that 
represent  areas  within  a  page  that  are  reserved  for  common  content. 

These  types  of  frame  have  fixed  positions  and  dimensions.  The  positioning  of  these  frames  within  a 
page  and  the  layout  paths  that  may  be  specified  for  them  depends  upon  the  H/F  layout  type  used  (see 
6.3.4.5) 

The  subordinates  of  these  frames  may  consist  of  either: 

a)  any  number  and  combination  of  variably  positioned  frames  of  the  types 
SourcedContentVariable  and  ArrangedContentVariable,  or; 

b)  any  number  and  combination  of  fixed  positioned  frames  of  the  types 
SourcedContentFixed  and  ArrangedContentFixed. 

In  case  b),  the  subordinate  frames  may  overlap  without  restriction. 
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6.3.7  Sourced  content  and  arranged  content  area  characteristics 


6.3.7.1  SourcedContentVariable 

A  SourcedContentVariable  frame  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that 
contains  common  content  derived  from  the  generic  logical  structure.  This  frame  is  variably  positioned 
and  is  used  for  the  positioning  content  which  is  generated  during  the  layout  process,  such  as  a 
character  sequence  containing  a  page  number,  a  chapter  title,  etc. 

This  frame  may  be  placed  in  the  body  area  as  well  as  the  header  or  footer  area: 

—  When  this  frame  is  in  the  header  or  footer  area,  it  is  the  immediate  subordinate  of  the 
frame  of  the  constituent  constraint  type  CompositeHeader  or  CompositeFooter. 

—  When  this  frame  is  in  the  body  area,  it  is  the  immediate  subordinate  of  the  frame  of  the 
constituent  constraint  type  VariableCompositeBody,  CompositeColumnVariable, 
CompositeColumnFixed,  CompositeCommon,  SnakingColumns  or  CompositeFloat. 

SnakingColumns  are  used  to  place  common  contents  in  the  multi-column  format.  CompositeFloat 
is  used  to  place  common  contents  along  side  a  figure  or  a  form. 

The  attribute  "logical  source"  must  be  specified  for  this  frame  to  indicate  the  particular  instance  of  the 
constituent  constraint  CommonContent  which  contains  the  content  to  be  laid  out. 

When  this  frame  is  a  subordinate  of  CompositeHeader  or  CompositeFooter; 

a)  the  layout  path  of  the  frame  is: 

-  270  degrees  for  H/F  layouts  A1  and  A2; 

- 180  degrees  for  H/F  layouts  B1  and  B2  (see  6.3.4.5  and  the  comment  in  7.4.3.21). 

b)  the  horizontal  dimension  of  the  frame  is: 

-  either  fixed  or  'maximum-size'  for  H/F  layouts  A1,  A2  and  82; 

-  either  fixed  or  'Rule-B'  for  H/F  layout  B1. 

c)  the  vertical  dimension  of  the  frame  is: 

-  either  fixed  or  'Rule-B'  for  H/F  layouts  A1  and  A2; 

-  either  fixed  or  maximum-size'  for  H/F  layout  B1 ; 

-  only  fixed  in  the  case  of  H/F  layout  B2. 

When  this  frame  is  a  subordinate  of  VariableCompositeBody,  CompositeColumnVariable, 
CompositeColumnFixed  or  CompositeCommon: 

a)  the  layout  path  of  the  frame  is  270,  0  or  180  degrees  for  body  layouts  A,  B  or  C 
respectively  (see  6.3.4.5  and  the  comment  in  7.4.3.21); 

b)  the  dimension  of  the  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  superior 
frame  is  either  fixed  or  maximum-size'; 
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c)  the  dimension  of  the  frame  in  the  directbn  parallel  to  the  layout  path  of  the  superior 
frame  is  either  fixed  or  'Rule-B'. 

When  this  frame  is  a  subordinate  of  SnakingColumns: 

a)  the  layout  path  of  the  frame  is  270.  0  or  180  degrees  for  body  layouts  A.  B  or  C 
respectively  (see  6.3.4.5  and  the  comment  in  7.4.3.21); 

b)  the  dimension  of  the  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  superior 
frame  is  either  'Rule-B'  or  maximum-size',  except  that  only  maximum-size'  is  permitted 
for  body  layout  C; 

c)  the  dimension  of  the  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior 
frame  is  fixed. 

When  this  frame  is  a  subordinate  of  CompositeFloat: 

a)  the  layout  path  of  the  frame  is  270.  0  or  180  degrees  for  body  layouts  A.  B  or  C 
respectively  (see  6.3.4.5  and  the  comment  in  7.4.3.21); 

b)  the  dimension  of  the  frame  in  the  direction  orthogonal  to  the  layout  path  of  the  superior 
frame  is  either  fixed.  'Rule-B'  or  maximum-size"; 

c)  the  dimension  of  the  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior 
frame  is  either  fixed  or  'Rule-B'. 


6.3.7.2  ArrangedConteniVariable 

An  ArranqedContentVariable  frame  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that 
contains  pre-defined  common  content  contained  in  the  generic  layout  structure.  This  frame  is  variably 
positioned,  and  its  dimensions  are  fixed. 

This  frame  references  one  or  more  blocks  of  type  GenericBlock  (see  6.3.8)  which  contain  the  content  to 
be  laid  out  in  this  frame.  Thus,  this  frame  is  typically  used  when  it  is  required  to  layout  pre-determined 
common  content. 


6.3.7.3  SourcedContentFixed 

A  SourcedContentFixed  frame  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  contains 
common  content  derived  from  the  generic  logical  structure.  This  frame  has  a  fixed  position  and 
dimensions. 


This  frame  is  required  to  specify  the  attribute  "logical  source"  which  indicates  the  particular  instance  of 
the  constituent  constraint  CommonContent  which  contains  the  content  to  be  laid  out  in  this  frame. 


This  frame  may  be  placed  in  the  body  area  as  well  as  the  header  or  footer  area: 

—  When  this  frame  is  in  the  header  or  footer  area,  the  frame  is  the  immediate  sulx)rdinate 
of  the  frame  of  the  constituent  constraint  type  CompositeHeader  or  CompositeFooter; 
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—  When  this  frame  is  in  the  body  area,  the  frame  is  the  immediate  subordinate  of  the 
frame  of  the  constituent  constraint  type  FixedCompositeBody,  CompositeCommon  or 

.  SynchronizedColumns. 

When  this  frame  is  a  sut)ordinate  of  CompositeHeader  or  CompositeFooter: 

—  the  layout  path  of  this  frame  is  270  degrees  for  H/F  layouts  A1  and  A2; 

—  the  layout  path  of  this  frame  is  180  degrees  for  H/F  layouts  B1  and  82  (see  6.3.4.5). 

When  this  frame  is  a  subordinate  of  FixedCompositeBody,  CompositeCommon  or  SyncronizedColumns: 

—  the  layout  path  of  this  frame  is  270,  0  or  180  degrees  for  body  layouts  A,  B  or  C 
respectively  (see  6.3.4.5). 


Thus,  as  in  the  case  of  SourcedContentVariable  frames,  this  frame  is  used  for  the  positioning  of  content 
which  is  generated  during  the  layout  process,  such  as  a  character  sequence  containing  a  page  numl)er. 


6.3.7.4  ArrangedContentFixed 

An  ArrangedContentFixed  frame  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that 
contains  pre-defined  common  content  derived  from  the  generic  layout  structure.  The  position  and 
dimensions  of  this  frame  are  fixed. 

This  frame  references  one  or  blocks  of  type  GenericBlock  (see  6.3.8)  which  contain  the  content  to  be 
laid  out  in  this  frame.  Thus  this  frame  is  typically  used  when  it  is  required  to  layout  common  content  at 
pre-determined  positions  in  the  header  or  footer  areas. 


6.3.8  GenericBlock  and  SpecificBlock 

Two  types  of  constituent  constraints  of  the  type  'block'  are  defined,  namely  GenericBlock  and 
SpecificBlock. 

Object  classes  of  the  type  GenericBlock  may  occur  in  the  generic  layout  structure  referenced  by  the 
"generator  for  sutx)rdinates"  of  object  classes  of  the  types  ArrangedContentVariable  and 
ArrangedContentFixed.  When  the  layout  process  is  performed  to  produce  a  document  in  formatted 
processable  form,  equivalent  blocks  may  occur  in  the  specific  layout  structure. 

Objects  of  the  type  SpecificBlock  shall  only  occur  in  the  specific  layout  structure.  They  are  created 
during  the  document  layout  process  and  result  from  the  layout  of  basic  logical  objects  into  lowest  level 
frames  that  constitute  the  body,  header  and  footer  areas. 


6.4  Document  layout  characteristics 

Mechanisms  for  controlling  the  allocation  of  logical  constituents  to  various  areas  in  the  layout  structure 
are  defined  in  6.4.1 .  I^echanisms  for  controlling  the  layout  of  the  content  within  the  allocated  areas  are 
defined  in  6.4.2. 

These  mechanisms  relate  to  documents  for  which  a  generic  layout  structure  is  specified.  When  a 
generic  layout  structure  is  not  present,  then  these  mechanisms  are  restricted  as  described  in  6.4.3. 
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6.4.1  Flow  controls 


Various  mechanisms  are  provided  to  control  the  allocation  of  constituent  constraints  representing  the 
'body'  parts  of  the  logical  structure  of  a  document  to  page  sets,  pages  and  body  areas.  These  are 
described  in  6.4.1.1,  6.4.1.2  and  6.4.1.3.  The  mechanisms  for  controlling  the  layout  of  the  common' 
parts  of  a  document  are  described  in  6.4.1.4. 


6.4.1 .1  Allocation  of  content  to  page  sets 

Two  methods  of  allocating  the  constituent  constraints  associated  with  the  'body'  part  of  the  document  to 
page  sets  are  provided. 

a)  layout  in  a  nominated  page  set: 

b)  starting  a  new  page  set. 

The  first  method  provides  the  ability  to  specify  that  a  part  of  a  document  is  to  be  laid  out  entirely  within 
a  specified  page  set.  This  may  be  specified  for  constituent  constraints  of  the  types  Passage, 
NumberedSegment,  Paragraph.  Figure,  NumberedList,  UnNumberedList  and  DefinitionList  using  the 
attribute  "layout  object  class"  which  specifies  the  object  class  identifier  of  the  required  class  of  page  set. 

The  second  method  provides  the  ability  to  specify  that  the  logical  objects  derived  from  a  particular 
logical  constituent  constraint  in  a  document  and  all  subsequent  parts  of  a  document  are  to  be  laid  out 
starting  at  the  beginning  of  a  new  page  set.  This  may  be  specified  for  logical  object  from  the  following 
logical  constituent  constraints: 

—  Passage: 

—  NumberedSegment: 

—  Number; 

—  Title: 

—  Paragraph; 
.   —  Figure: 

—  NumberedList: 

—  UnNumberedList: 

—  DefinitionList: 

—  BodyText; 

—  BodyRaster; 

—  BodyGeometric. 

This  is  achieved  using  the  attribute  "new  layout  object"  which  specifies  the  object  class  identifier  of  the 
required  class  of  page  set. 
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6.4.1.2  Page  breaks 


This  provides  the  ability  to  specify  that  the  logical  objects  derived  from  a  particular  logical  constituent 
constraint  in  a  document  and  all  subsequent  parts  of  a  document  are  to  be  laid  out  starting  at  the 
beginning  of  a  new  page.  The  page  specified  shall  belong  to  the  page  set  in  which  the  logical  objects 
from  the  immediate  preceding  logical  constituent  constraint  is  laid  out  (see  note). 

This  may  be  specified  for  logical  objects  from  the  following  logical  constituent  constraints: 

—  Passage; 

—  NumberedSegment; 

—  Number; 


!        —  Paragraph; 

—  Figure; 

—  NumberedList; 

—  UnNumberedList; 

—  DefinitionList; 

—  BodyText; 

—  BodyRaster; 

j        —  BodyGeometric. 

This  is  achieved  using  the  attribute  "new  layout  object".  This  attribute  may  specify  the  value  page' 
indicating  that  the  logical  object  is  to  be  laid  out  starting  on  the  next  available  page  which  may  be  of 

(I  any  class.  Alternatively,  the  attribute  may  specify  an  object  class  identifier  indicating  the  page  class 

j  that  the  object  is  to  be  laid  out  in. 

NOTE  18  -  The  specification  of  a  page  breaks  sliall  not  be  used  to  layout  part  of  a  document  in  a  new  page 
set.  If  a  new  page  set  is  required,  tlien  this  shall  be  explicitly  specified  as  described  in  6.4.1.1. 


6.4.1.3  Allocation  of  content  to  body  areas 


6.4.1.3.1  Introduction 

I  If  the  page  to  which  the  content  is  allocated  contains  a  basic  body  area,  then  the  content  is  laid  out  in 
sequential  order  in  that  body  area  in  the  form  of  a  single  column. 

If  the  page  contains  a  composite  body  area,  i.e.,  a  VariableCompositeBody  or  FixedCompositeBody 
•  frame,  then  the  content  is  allocated  to  subordinate  areas  in  that  body  area  as  described  below. 

!  The  general  layout  mechanism  is  described  in  6.4.1.3.2.  However,  particular  layout  facilities  are 
provided  for  the  layout  of  logical  constituent  constraints  of  the  type  Table  (see  6.4.1.3.8)  and  the  type 
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Figure,  which  may  contain  either  Artwork  or  Forms  (see  6.4.1 .3.7).  Also,  the  layout  of  Footnotes  is  i 
described  in  6.4.1.3.10.  i 


6.4.1.3.2  General  mechanism  for  Saying  out  content  in  a  composite  body  area 

When  laying  out  content  into  a  composite  t>ody  area  having  more  than  one  sutx)rdinate  frame  class 
{excluding  Footnote  Area  frame  classes),  it  is  necessary  to  indicate,  directly  or  indirectly,  which  of  the 
possible  areas  is  to  be  used. 

Basic  logical  objects  other  than  those  which  are  within  a  footnote  structure  may  be  specified  to  be  laid  | 
out  in  instances  of  one  or  more  lowest  level  frame  class.  This  is  done  by  giving  each  such  basic  logical 
component  a  vaiue  of  the  attribute  "layout  category"  which  corresponds  to  the  value  of  the  attribute 
"permitted  categories"  that  applies  to  the  lowest  level  frame  in  which  the  content  is  to  be  laid  out. 

Note  that  any  basic  logical  objects  in  the  specific  logical  structure  to  which  this  attribute  does  not  apply 
will  be  laid  out  only  in  a  lowest  level  frame  which  has  the  implicit  value  of  the  attribute  "permitted 
categories". 

The  use  of  the  attribute  "layout  category"  ensures  that  if  there  is  insufficient  area  on  one  page  to  lay  out 
all  of  the  content  allocated  to  a  particular  type  of  area,  the  laying  out  of  the  content  will  automatically 
continue  in  the  same  type  of  area  in  a  succeeding  page  when  possible.  Thus  content  is  allowed  to  flow 
freely  from  one  page  to  another  when  the  type  of  layout  used  at  the  end  of  one  page  is  the  same  as 
tnat  at  the  beginning  of  the  succeeding  page.  When  continuation  to  the  same  type  of  area  in  a 
succeeding  page  is  not  possible  because  of  conflict  with  other  layout  directives  or  because  the 
"generator  for  sut)ordinates"  of  the  page  class  does  not  allow  such  choice,  backtracking  may  occur  or 
other  type  of  area  may  be  selected. 

It  is  necessary  to  ensure  the  correct  use  of  the  mechanism  for  the  layout  of  independent  layout 
streams.  In  the  absence  of  additional  layout  directives,  content  may  be  placed  in  available  space  within 
an  earlier  frame  of  the  specified  "permitted  categories".  If  this  is  not  intended,  it  may  be  prevented  by 
the  use  of  the  attribute  "new  layout  object"  (or  "layout  object  class"  in  some  cases). 

The  attribute  "new  layout  object"  may  be  applied  to  logical  components  whenever  a  change  in  layout  is 
required.  The  attribute  "new  layout  object"  may  specify  the  identifier  or  the  category  name 
corresfxinding  to  the  frame  class  that  is  required. 

When  layout  occurs  in  a  snaking  columns  area,  column  breaks  may  be  indicated  by  using  the  attribute 
"new  layout  object".  This  attribute  may  specify  the  identifier  or  the  category  name  of  the  frame 
corresponding  to  the  column  in  which  the  layout  is  to  continue.  However,  only  the  use  of  category 
name  will  ensure  that  a  single  column  break  is  always  obtained,  irrespective  of  the  frame  class  actually 
used. 

When  the  layout  is  to  occur  in  a  synchronized  columns  area,  category  names  may  be  used  to  control 
the  particular  columns  that  are  to  be  used  to  lay  out  the  logical  entities.  Each  column  within  a 
synchronized  columns  area  shall  have  a  different  permitted  category  and  each  basic  logical  object  to  be 
laid  out  in  this  particular  area  shall  have  a  category  name  corresponding  to  a  name  allocated  to  one  of 
the  columns.  The  logical  entities  allocated  to  different  columns  may  be  aligned  using  the  attribute 
"Synchronization". 

The  following  subclauses  describe  the  layout  mechanism  applicable  to  subordinate  areas  for  each  of 
the  frame  types  listed  alx)ve. 
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6.4.1.3.3  Layout  into  BasicFloat  and  BasicFixture  frames 

These  are  lowest  level  frames  and  hence  content  continues  to  be  directly  laid  out  in  these  frame  types 
until  an  occurrence  of  the  attribute  "new  layout  object"  causes  the  layout  to  proceed  starting  with  an 
alternative  frame  class. 


6.4.1.3.4  Layout  in  SnaltingColumns  frames 


A  SnakingColumns  frame  is  a  composite  frame  which  contains  columns  represented  by  lowest  level  or 
composite  frames. 

In  the  case  ot  lowest  frames,  all  the  frames  may  have  the  same  category  name  so  that  content  can 
flow  from  one  frame  to  the  next.  That  is,  a  column  break  will  occur  naturally  when  the  size  of  one 
column  reaches  the  limit  imposed  by  the  superior  frame  and  the  layout  process  will  continue 
automatically  in  the  next  column. 

In  the  case  of  composite  columns,  the  subordinate  areas  are  represented  by  subordinate  frames  of  the 
types  BasicFloat,  CompositeFloat,  CompositeFixtureVariable,  TableArea  and  FootnoteArea.  The  frame 
type  into  which  the  constituents  are  to  be  laid  out  is  selected  using  the  attribute  "new  layout  object" 
which  indicates  the  identifier  or  category  name  of  the  required  subordinate  frame,  or  is  automatically 
selected  according  to  "layout  categories".  Logical  constituents  will  continue  to  be  laid  out  in  the 
selected  frame  type  until  a  different  frame  type  is  selected.  Also,  the  layout  process  continues 
automatically  from  one  column  to  the  next,  but  column  breaks  can  again  be  forced  as  described  in 
6.4.1.3.2. 


6.4.1.3.5  Layout  in  SynchronizedColumns  frames 

A  SynchronizedColumns  frame  is  a  composite  frame  which  contains  columns  represented  by 
subordinate  lowest  level  or  composite  frames. 

In  the  case  of  lowest  frames,  all  the  frames  are  required  to  have  different  categories.  Hence,  the  layout 
of  logical  objects  from  the  constituents  into  different  columns  is  controlled  by  the  category  name 
specified  for  each  constituent.  The  attribute  "new  layout  object"  may  also  be  used  for  this  purpose,  but 
this  is  not  necessary. 

In  the  case  of  composite  columns,  the  subordinate  areas  are  represented  by  sutx)rdinate  frames  of  the 
types  BasicFloat,  CompositeFloat,  CompositeFixtureVariable,  TableArea  and  FootnoteArea. 

The  selection  of  a  particular  composite  column  or  a  particular  sub-area  within  a  composite  column  can 
be  achieved  using  the  attribute  "new  layout  object"  which  specifies  the  identifier  or  category  name  of 
the  particular  frame  class  required. 


6.4.1.3.6  Layout  in  CompositeFioat  frames 

This  is  a  composite  frame  which  contains  two  or  more  subordinate  frames  that  are  laid  out  side-by- 
side".  The  appropriate  sut)ordinate  frame  is  chosen  according  to  the  category  names  or  chosen  using 
the  attribute  "new  layout  object"  which  specifies  the  appropriate  identifier  or  category  name  of  the 
required  subordinate  frame  class. 
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6.4.1.3.7  Layout  of  Figures 

Frames  of  the  types  CompositeFixtureVariable  and  Composite FixtureFixed  are  provided  specifically  for 
the  layout  of  logical  constituent  constraints  of  the  type  Figure.  Similarly,  frames  of  the  type 
CompositeArtwork  and  FormArea  are  provided  for  the  layout  of  logical  constituent  constraints  of  the 
types  Artwork  and  Form  respectively.. 

The  schematic  diagram  in  table  2  shows  how  the  logical  constituent  constraint  Figure  and  its 
subordinates  are  allocated  to  the  frame  CompositeFixtureVariable  or  CompositeFixtureFixed  and  their 
subordinates. 


Table  2  —  Layout  of  Figure 


Logical  constituent  constraint 

Frame  class 

Figure  > 

ComposrteFixtureVariable  or  CompositeFixtureFixed 

Artwork  > 

CompositeArtwork 

Phrase  > 

BasicFixture 

Body  Raster  > 

BasicFixture 

BodyGeometric  > 

BasicFixture 

Form  > 

FormArea 

EntryGroup  > 

EntryGroupArea 

EntryElement  ....> 

FormEntryArea 

Number  > 

BasicFloat 

Caption  > 

BasicFloat 

Description  > 

BasicFloat 

Footnote  > 

FootnoteArea 

Table  2  indicates  a  mapping  between  logical  constituent  constraints  and  frames,  and  their  respective 
subordinates.  Also,  the  diagram  indicates  that  this  mapping  is  hierarchical. 

For  example,  Figure  is  to  be  laid  out  into  a  single  instance  of  the  frame  CompositeFixtureVariable  or 
CompositeFixtureFixed.  A  subordinate  constituent  constraint  of  the  type  Artwork  is  to  be  laid  out  in  a 
single  instance  of  a  frame  of  type  CompositeArtwork  within  the  specified  CompositeFixtureVariable  in  a 
CompositeFixtureFixed  frame. 

Also,  each  instance  of  a  subordinate  Phrase,  BodyRaster  or  BodyGeometric  is  to  be  laid  out  in  a  single 
instance  of  a  subordinate  frame  of  the  type  BasicFixture.  BasicFixture  frames  may  overlap  to  form  a 
composite  image. 

Similarly,  a  Form  is  to  be  laid  out  in  a  single  instance  of  a  FormArea  frame.  Frames  subordinate  to  this 
FormArea,  that  is,  EntryGroupArea  and  FormEntryArea  frames,  will  each  receive  single  instances  of 
logical  constituent  constraints  of  the  type  EntryGroup  and  EntryElement  respectively. 
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This  layout  mechanism  is  achieved  by  specifying  the  attribute  "new  layout  object"  for  Figure  with  a 
value  Indicating  the  identifier  of  the  appropriate  frame  classes  in  which  that  constituent  is  to  be  laid  out. 

The  constituent  constraints  Number,  Caption  and  Description  (and  their  subordinates  in  the  case  of 
Caption  and  Description)  are  laid  out  in  frames  of  the  type  BasicFloat.  This  is  achieved  automatically 
according  to  category  names  or  explicitly  using  the  attribute  "new  layout  object"  which  indicates  the 
Identifier  or  category  name  of  the  frame  class  required.  More  than  one  instance  of  the  constituent 
constraints  Caption,  Deschption  and  Number  may  be  laid  out  in  a  particular  BasicFloat  frame. 

Frames  of  the  type  FootnoteArea  may  be  generated  within  a  CompositeFixtureVariable  or 
CompositeFixtureFixed  to  accommodate  instances  of  the  logical  constituent  constraint  Footnote  which 
occurs  as  a  subordinate  of  Phrase.  Caption  or  Description. 


6.4.1.3.8  Layout  of  Tables 

Frames  of  the  type  TableArea  are  provided  specifically  for  the  layout  of  logical  constituent  constraints  of 
the  type  Table. 

Table  3  Illustrates  the  relationships  between  the  logical  constituent  constraint  Table  and  its 
subordinates,  and  the  frames  used  to  lay  out  these  constituent  constraints. 


Table  3  —  Layout  of  Tables 


Logical  constituent  constraint 

Frame  class 

Table  > 

TableArea 

Row  > 

RowArea 

EntryElement  > 

Cell 

TableComponent  > 

SubRowGroup 

RowComponent  > 

SubRow 

EntryElement  > 

Cell 

CommonContent  <  

TableHeader 

CommonContent  <  

TableLabel 

Table  3  Indicates  that  there  Is  a  hierarchical  mapping  between  logical  constituent  constraints  and  their 
corresponding  frames.  For  example,  each  Row  is  to  be  laid  out  in  a  separate  frame  of  the  type 
RowArea.  Each  TableComponent  that  is  subordinate  to  that  Row  must  be  laid  out  In  a  specific 
SubRowGroup  that  is  subordinate  to  the  RowArea  indicated. 
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The  layout  mechanism  is  achieved  for  the  logical  constituent  constraints  Table,  Row  and 
RowComponent  by  specifying  the  attribute  "new  layout  object"  with  a  value  indicating  the  identifier  of 
the  required  frame  class  of  the  type  TableArea.  RowArea  and  SubRow  respectively. 

For  the  logical  constituent  constraint  Entry  Element,  the  layout  mechanism  is  achieved  by  one  of  the 
following: 

a)  If  the  attribute  "generator  for  subordinates"  of  the  superior  (RowArea  or  SubRow)  of  the 
affected  EntryElement  is  constaicted  using  SEQuence.  the  attribute  "new  layout  object" 
is  used  to  specify  a  Cell  into  which  the  contents  is  laid  out.  The  attribute  value  specifies 
the  Identifier  of  the  required  frame  class  in  the  EntryElement. 

b)  If  the  attribute  "generator  for  subordinates"  of  the  superior  (RowArea  or  SubRow)  of  the 
affected  EntryElement  is  constructed  by  REPetition,  the  value  of  the  attribute  "new 
layout  object"  indicates  a  category  name  to  be  used  for  the  EntryElement.  In  this  case, 
the  category  name  shall  be  specified  in  the  attribute  "layout  category"  for  EntryText, 
EntryRaster  or  EntryGeometric,  and  in  the  attribute  "permitted  categories"  for  the  Cell 
into  which  the  contents  is  laid  out. 

In  the  case  of  TableComponent,  the  attribute  "layout  object  class"  is  used  to  specify  that  this  logical 
constituent  constraint  is  to  be  laid  out  in  a  SubRowGroup  frame. 

This  mechanism  allows  a  table  to  be  laid  out  such  that  it  is  split  over  two  or  more  successive  frames  or 
pages.  A  split  may  occur  at  the  boundary  of  a  RowArea  frame,  or  such  that  a  RowArea  frame  is  split 
over  two  successive  frames  or  pages.  A  split  cannot  occur  within  a  SubRowGroup  frame. 

When  such  a  split  does  occur,  then  the  TableHeader  and  TableLabel  frames  are  repeated  at  the  top  of 
each  frame  of  page  in  which  the  table  is  continued. 

The  content  allocated  to  the  frames  TableHeader  and  TableLabel  are  derived  from  logical  constituent 
constraints  of  the  type  CommonContent  in  the  generic  logical  structure  using  the  logical  source' 
mechanism. 


6.4.1.3.9  Layout  Of  Forms 

Frames  of  the  type  FormArea  are  provided  specifically  for  the  layout  of  logical  constituent  constraints  of 
the  type  Form. 

Table  4  illustrates  the  relationships  between  the  logical  constituent  constraint  Form  and  its 
subordinates,  and  the  frames  used  to  lay  out  these  constituent  constraints. 

Table  4  indicates  there  is  a  hierarchical  mapping  between  logical  constituent  constraints  and  the 
corresponding  frames,  and  their  respective  subordinates. 

The  layout  mechanism  is  achieved  by  specifying  for  logical  constituent  constraints  the  attribute  "layout 
object  class"  which  indicates  the  object  class  identifier  of  an  appropriate  frame  in  accordance  with  the 
above  diagram.  This  mechanism  does  not  allow  frames  of  the  type  FormArea  to  be  split  over  two  or 
more  superior  frames. 

The  content  associated  with  the  logical  constituent  constraint  EntryElement  is  specified  by  one  of  the 
constituent  constraints  EntryText.  EntryRaster  or  EntfyGeometric.  The  layout  of  this  content  is 
controlled  by  the  layout  directives  "offset"  and  "block  alignment" 
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Table  4  —  Layout  of  Forms 


Logical  constituent  constraint 

Frame  class 

Form  > 

FormArea 

EntryGroup  > 

EntryGroupArea 

EntryElement  > 

FormEntryArea 

6.4.1.3.10  Layout  of  Footnotes 

I  The  logical  objects  derived  from  basic  logical  constituent  constraints  that  represent  the  content 
belongirig  to  a  footnote  (i.e.,  FootnoteReference,  FootnoteNumber  and  FootnoteText)  are  constrained  to 
be  laid  out  in  a  footnote  area  which  is  represented  by  a  FootnoteArea  frame  (see  6.3.5.20). 

I  This  constraint  is  specified  by  means  of  category  names.  That  is,  the  logical  constituent  constraints  of 
I  the  types  FootnoteNumber  and  FootnoteText,  and  layout  constituent  constraints  of  the  type 
FootnoteArea  are  all  required  to  have  the  category  name  'Footnote'  or  'Footnote  <n>'. 

More  than  one  footnote  may  be  placed  in  a  footnote  area.  In  this  case,  the  content  belonging  to  the 
footnotes  are  laid  out  sequentially  in  the  footnote  area  in  accordance  with  their  reading  order. 

If  the  content  belonging  to  a  footnote  cannot  all  be  accommodated  in  the  footnote  area  on  one  page, 
then  the  content  may  freely  flow  into  the  next  footnote  area.  Alternatively,  it  is  possible  fo  specify  that  a 
footnote  is  to  be  laid  out  entirely  within  a  particular  footnote  area.  This  is  achieved  using  the  attribute 
"indivisibility". 


6.4.1.4  Allocation  of  content  to  header  and  footer  areas 

A  header  or  footer  area  may  be  basic  or  composite  (see  6.3.6.1).  In  the  case  of  a  basic  area,  the 
frame  representing  that  area  specifies  the  attribute  "logical  source"  which  indicates  the  particular 
Instance  of  the  constituent  constraint  of  the  type  CommonContent  that  is  to  be  laid  out  in  that  area. 
The  basic  logical  constituent  constraints  subordinate  to  CommonContent  are  then  laid  out  in 
accordance  with  their  sequential  order. 

In  the  case  of  a  composite  header  or  footer  area  (see  6.3.6.3),  the  area  is  divided  into  one  or  more 
separate  areas,  each  of  which  is  represented  by  a  lowest  level  frame.  The  content  allocated  to  the 
separate  areas  may  be  derived  from  one  of  two  sources.  That  is,  the  content  may  be  pre-defined  and 
represented  by  one  or  more  blocks  which  are  directly  associated  with  the  lowest  level  frame. 
Alternatively,  the  lowest  level  frame  may  specify  the  attribute  "logical  source"  which,  as  above,  indicates 
the  particular  logical  object  of  the  type  CommonContent  that  is  to  be  laid  out  in  that  frame. 


6.4.2  Layout  of  document  content 

Various  constraints  may  be  specified  to  control  the  layout  of  the  content  into  the  body,  header  and 
footer  areas.  These  constraints  are  described  below. 
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6.4.2.1  Margins 


The  margins  are  the  minimum  distances,  or  offsets,  between  a  part  of  the  document  content  and  the 
edge  of  the  particular  area  in  which  that  content  is  laid  out.  The  margins  define  the  maximum  extents 
of  the  available  area  into  which  the  content  shall  be  positioned. 

Margins  may  be  specified  for  any  constituent  constraint  representing  a  basic  logical  object;  different 
margin  values  may  be  specified  for  different  constituent  constraints  without  restriction. 

Four  margins  may  be  independently  specified  for  each  constituent  constraint,  namely; 

—  trailing  edge  margin; 

—  leading  edge  margin; 

—  right  hand  edge  margin; 

—  left  hand  edge  margin. 

These  margins  are  defined  in  relationship  to  the  layout  path  specified  for  the  frame  into  which  the 
content  is  to  be  laid  out  (see  figure  18). 

Any  combination  of  the  above  margins  may  be  specified  for  a  particular  constituent  constraint.  These 
margins  are  specified  by  the  attribute  "offset".  Any  value  may  be  specified  in  units  of  SMUs.  If  a 
particular  margin  is  not  specified,  then  it  is  assumed  to  be  0  SMUs. 


6.4.2.2  Separation 

Leading  separation  is  the  minimum  distance  between  one  basic  logical  object  and  the  next  one.  if  any 
when  they  are  laid  out.  Trailing  separation  is  the  minimum  distance  between  one  basic  logical  object 
and  the  previous  one,  if  any,  when  they  are  laid  out.  Both  may  be  specified  for  basic  logical 
components  of  any  constituent  constraint  types.  These  distances  are  specified  in  SMUs  by  the 
attritxjte  "separation".  If  no  value  is  specified,  then  the  minimum  distance  is  assumed  to  be  0  SMUs. 


6.4.2.3  Indivisibility 

Indivisibility  provides  the  means  to  specify  whether  or  not  a  logical  object  derived  from  a  basic  or 
composite  logical  constituent  constraint  is  altowed  to  be  split  over  more  than  one  page  or  over  more 
than  one  area  within  a  page.  It  may  be  specified  for  logical  objects  from  constituent  constraints  of  the 
types  Passage.  NumberedSegment,  Number.  Title.  Paragraph.  Captbn.  Phrase.  Reference. 
Description.  Listltem,  ListTerm,  FootnoteText.  ReferencedContent,  FootnoteBody.  Artworl<, 
EntryElement,  Row.  RowComponent,  Footnote.  Figure.  Table.  UnNumberedList.  Numt)eredList. 
DefinitionList,  FootnoteReference  and  BodyText.  The  attribute  "indivisibility"  is  used  to  specify  this 
feature. 


6.4.2.4  Same  layout  object 

Same  layout  object  provides  the  means  to  specify  that  the  start  of  the  content  associated  with  a  logical 
object  and  the  end  of  the  content  associated  with  the  previous  logical  object  are  to  be  laid  out  within  a 
single  layout  object.  This  may  be  specified  for  togical  objects  of  the  types  Passage. 
NumberedSegment,  Title.  Caption,  Number.  Paragraph,  Phrase,  Footnote,  FootnoteBody,  Figure, 
FootnoteReference.  ReferencedContent,  Reference,  Description,  Table,  NumberedList, 
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Figure  18  —  Specification  of  margins 


UnNumberedList,  DefinitionList,  Listltem,  ListTerm,  BodyText.  BodyRaster  and  BodyGeometric.  The 
attribute  "same  layout  object"  is  used  to  specify  this  feature. 


6.4.2.5  Concatenation 


Concatenation  provides  the  means  to  specify  that  the  content  associated  with  a  togical  object  derived 
from  a  basic  logical  constituent  constraint  and  the  content  associated  with  the  previous  basic  logical 
object  are  to  be  regarded  as  an  unbroken  stream  of  content.  This  may  t>e  specified  for  togical  objects 
from  constituent  constraints  of  the  types  BodyText,  Number.  ReferencedContent,  FootnoteReference, 
FootnoteText.  TableNumber,  Currentlnstance,  CommonNumber,  CommonReference,  CommonText  and 
PageNumber.  The  attribute  "concatenation"  is  used  to  specify  this  feature. 


6.4.2.6  Blocl(  alignment 

Block  alignment  allows  the  content  associated  with  a  basic  togical  object  to  be  specified  as  'left 
aligned",  right  aligned'  or  centred'  within  the  area  in  which  that  content  is  laid  out.  Left  aligned  means 
that  the  content  is  laid  out  adjacent  to  the  left  hand  edge  margin.  Right  aligned  means  that  the  content 
is  laid  out  adjacent  to  the  right  hand  edge  margin,  and  centred  means  that  the  content  is  laid  out 
midway  between  the  left  and  right  margins. 
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This  feature  may  only  be  specitied  using  the  attribute  "block  alignment"  for  logical  objects  from 
constituent  constraints  of  the  types  BodyText,  EntryText,  Number,  CommonNumber,  PageNumber, 
TableNumber,  FootnoteNumber,  FootnoteText,  FootnoteReference,  CommonReference, 
ReferencedContent,  Currentlnstance,  and  CommonText,  and  when  they  contain  formatted  character 
content,  BodyRaster,  and  BodyGeometric,  EntryRaster,  EntryGeometric,  CommonRaster  and 
CommonGeometric. 


6.4.3  Layout  controls  applicable  in  the  absence  of  a  generic  layout  structure 

! 

In  processable  form  documents  the  generic  layout  structure  is  optional.  If  the  generic  layout  structure  is  j 
omitted,  then  it  is  the  responsibility  of  the  receiver  to  define  an  appropriate  layout  structure.  No  i 
limitations  are  placed  on  the  layout  structure  that  is  used. 

When  a  generic  layout  structure  is  not  specified  within  a  processable  form  document,  then  restrictions 
are  placed  on  the  layout  control  functions  described  in  6.4.1  and  6.4.2  that  may  be  specified  within  the 
document.  These  restrictions  are  indicated  as  follows: 

a)  It  is  not  possible  to  specify  that  certain  logical  parts  of  a  document  are  to  be  allocated 
to  a  given  page  set  or  that  a  part  of  a  document  is  to  be  laid  out  starting  in  a  new  page 
set,  as  defined  in  6.4.1.1; 

b)  It  is  possible  to  specify  page  breaks  as  defined  in  6.4.1.2,  but  it  is  only  possible  to 
indicate  that  the  layout  shall  begin  on  a  new  page.  It  is  not  possible  to  specify  a 
particular  page  class; 

c)  The  logical  parts  of  the  document  that  are  intended  to  be  laid  out  in  the  body  area  and 
in  the  header/footer  areas  of  each  page  may  be  distinguished  from  each  other  by 
means  of  application  comments  specified  for  them  (see  6.6.5).  An  exception  is  that  it  is 
not  possible  to  distinguish  whether  a  particular  portion  of  common  content  is  to  be 
placed  in  a  header  or  a  footer  area  (or  both); 

d)  It  is  not  possible  to  indicate  the  type  of  layout  area  to  be  used  to  layout  each  logical 
constituent  in  the  body  part  of  a  document.  That  is,  It  is  not  possible  to  indicate 
whether  single  column  or  multiple  column  areas  are  to  be  used  (see  6.4.1.3).  This 
shall  be  decided  by  the  receiver; 

e)  Footnotes  within  the  tx)dy  part  of  a  document  may  be  distinguished  by  use  of  the 
attribute  "application  comments".  Footnotes  are  intended  to  be  read  and  laid  out 
separately  from  the  other  logical  constituents  of  the  t)ody  part  (see  6.4.1 .3).  However, 
It  is  the  responsibility  of  the  receiver  to  decide  how  footnotes  are  laid  out; 

f)  Margins,  separation,  indivisibility,  same  layout  object,  concatenation  and  block 

alignment,  as  defined  in  6.4.2,  may  all  be  specified.  Only  one  restriction  applies. 
Indivisibility  (see  6.4.2.3)  may  be  assumed  to  specify  that  a  logical  constituent 
constraint  is  not  to  split  over  more  than  one  page,  but  indivisibility  shall  not  be  specified 
for  other  types  of  layout  areas,  such  as  single  or  multiple  column  areas. 


6.5  Content  layout  and  imaging  characteristics 

A  document  may  contain  character,  raster  graphics  and  geometric  graphics  content. 

The  content  architectures  that  may  be  specified  using  the  attribute  "content  architecture  class"  are 
formatted  character,  processable  character,  formatted  processable  character,  formatted  processable 
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raster  graphics  and  formatted  processable  geometric  graphics.  Any  of  these  may  be  specified  as  the 
default  in  the  document  profile. 

6.5.1  Character  content 

6.5.1.1  Introduction 

This  sulxlause  defines  the  features  that  are  applicable  to  the  character  content  contained  in  a 
document  and  the  presentation  attributes  and  control  functions  that  may  be  used  to  specify  these 
features.  These  features  may  apply  to  basic  logical  and  layout  components  unless  othenwise  indicated. 

The  default  values  for  the  following  features  may  be  specified  in  the  document  profile: 

—  graphic  character  sets; 

—  graphic  character  subrepertoire; 

—  code  extension  announcers; 

—  line  spacing; 

—  character  spacing; 

—  character  path; 

—  line  progression; 

—  character  orientation; 

—  graphic  rendition,  including  the  parameter  values:  default  rendition,  increased  intensity 
(bold),  italicized,  underlined,  crossed-out,  slowly  blinking,  rapidly  blinking,  negative 
image,  positive  image,  primary  font,  1st  alternative  font,  2nd  alternative  font,  3rd 
altemative  font,  4th  alternative  font,  5th  alternative  font,  6th  alternative  font.  7th 
alternative  font,  8th  altemative  font.  9th  alternative  font,  doubly  underlined,  normal 
intensity,  not  italicized,  decreased  intensity,  not  underlined,  not  blinking,  not 
crossed-out; 

—  line  layout  table; 

—  indentation; 

—  alignment; 

—  first  line  offset; 

—  itemization; 

—  widow  size; 

—  orphan  size; 

—  character  fonts; 
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—  kerning  offset; 

—  painvise  kerning; 

—  proportional  line  spacing; 

—  formatting  indicator; 

—  initial  offset. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation  attribute  or  control  function 
shall  be  indicated  in  the  document  profile. 


6.5.1.2  Character  content  architecture 

Processabie  and  formatted  processable  form  documents  may  contain  processable.  formatted  or 
formatted  processable  character  content.  Formatted  form  documents  may  contain  formatted  and 
formatted  processable  character  content. 

When  using  character  content,  any  number  of  content  portions  may  be  associated  with  a  basic 
component. 

The  content  information  in  a  content  portion  may  be  absent.  This  is  to  allow  the  representation  and 
interchange  of  documents  in  which  parts  of  the  content  may  be  supplied,  for  example,  during 
subsequent  editing. 

6.5.1.3  Character  repertoire 

The  basic  character  repertoire  supported  by  this  profile  is  composed  of  the  94  characters  of  ISO- 
IR6(the  IRV  of  ISO  646  revised  1991)  plus  the  character  space 

Any  other  graphic  character  set  which  is  registered  in  accordance  with  ISO  2375  may  be  designated 
and  invoked  at  any  point  in  the  document  provided  its  use  is  indicated  in  the  document  profile  as  a 
non-basic  value  using  the  character  presentation  feature  "graphic  character  sets".  No  locking  shift 
functions  are  specified  in  this  presentation  feature. 

The  code  extension  techniques  allowed  for  the  designation  and  invocation  of  character  sets  to  the  left 
hand  side  and  right  hand  side  of  the  8-bit  code  table  (GL  and  GR  respectively)  are  defined  in  6.5.1 .4. 

Using  these  code  extension  techniques,  the  graphic  character  sets  designated  and/or  invoked  at  the 
beginning  of  a  content  portion  containing  character  content  are  specified  using  the  presentation  attribute 
"graphic  character  sets".  The  character  sets  may  also  be  changed  at  any  point  within  a  content  portion. 

The  default  graphic  character  sets  which  apply  to  the  content  portions  within  a  document  may  be 
specified  in  the  document  profile  using  the  presentation  attribute  "graphic  character  sets". 

If  the  character  set  defined  in  ISO  6937-2  with  or  without  Addendum  1  is  designated  and  invoked,  then 
the  use  of  any  of  its  subrepertoires  registered  according  to  ISO  7350  may  be  specified  using  the 
presentation  attribute  "graphic  character  subrepertoire".  All  subrepertoires  are  non-basic  and  their  use 
shall  be  indicated  in  the  document  profile.  The  subrepertoire  shall  not  be  changed  within  a  content 
portion. 

NOTE  19  -  The  basic  character  repertoire  supported  by  this  profile  is  not  the  standard  default  value  specified  in 
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(CCITT  Recommendation  T.416  |  ISO  8613-6];  hence  it  may  be  necessary  to  specify  in  the  document  profile  of 
a  particular  document  that  this  is  the  default  value  being  used  for  that  document. 

NOTE  20  -  Revised  CCITT  Recommendations  T.50  and  T.51  and  new  CCITT  Recommendation  T.52  are  under 
preparation.  CCITT  Recommendations  T.50  and  T.51  are  intended  to  be  completely  compatible  with  ISO  646 
revised  1991  (ISO  IR-6)  and  ISO  6937  (under  revision)  respectively. 


6.5.1.4  Code  extension  techniques 

The  code  extension  techniques  specified  in  ISO  2022  may  be  used  subject  to  the  following  restrictions: 

a)  GO  set:  only  IS0-IR6  (the  IRV  of  ISO  646  revised  1991),  IS0-IR2  (the  primary  set  of 
ISO  6937-2),  or  any  other  version  of  ISO  646  (revised  1991)  may  be  designated  as  the 
GO  set;  these  graphic  character  sets  may  only  be  invoked  in  GL; 

b)  G1,  G2,  G3  sets:  no  restrictions  are  placed  on  the  character  sets  that  may  be 
designated  tor  these  sets;  these  graphic  character  sets  may  only  be  invoked  in  GR; 

c)  The  locking  and  single  shift  functions  allowed  are  as  follows: 

1)  LSO,  to  invoke  the  GO  set  into  GL; 

2)  LS1R.  to  invoke  the  G1  set  into  GR; 

3)  LS2R,  to  invoke  the  G2  set  into  GR; 

4)  LS3R,  to  invoke  the  G3  set  into  GR; 

5)  SS2,  to  invoke  one  character  from  the  G2  set  into  GL; 

6)  SS3,  to  invoke  one  character  from  the  G3  set  into  GL; 

NOTE  21  -  GL  and  GR  refer  to  the  left  and  right  hand  parts  respectively  of  the  8-bit  code  table. 

d)  When  specifying  the  presentation  attribute  "graphic  character  sets",  it  is  necessary  to 
invoke  character  sets  for  both  GL  and  GR.  Thus  an  allowed  character  set  shall  be 
designated  into  GO  (see  item  (a)  above)  and  invoked  into  GL.  It  is  also  necessary  to 
invoke  a  graphic  character  set  into  GR  which  has  been  designated  into  the  G1 ,  G2  or 
G3  set; 

e)  The  empty  set  shall  be  designated  into  G1  and  invoked  into  GR  if  no  other  specific 
graphic  character  set  is  invoked  into  GR; 

The  code  extension  techniques  allowed  are  illustrated  in  figures  19  and  20. 

The  announcement  and  encoding  of  these  functions  are  to  be  as  specified  in  ISO  2022. 

The  code  extension  techniques  that  are  used  or  may  be  used  in  a  basic  component  shall  be  specified 
by  the  presentation  attribute  "code  extension  announcers."  The  default  code  extension  announcers 
used  throughout  a  document  may  be  specified  in  the  document  profile,  also  using  the  presentation 
attribute  "code  extension  announcers". 

NOTE  22  -  In  accordance  with  [CCITT  Recommendation  T.416  |  ISO  8613-6],  there  is  no  restriction  concerning 
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the  number  of  graphic  character  sets  which  may  be  designated  and/or  invoked  in  the  presentation  attribute 
"graphic  character  sets"  providing  the  restrictions  defined  in  this  subclause  are  applied.    Hence  designatbn  to 
a  particular  G  set  overrides  a  previous  designation  to  that  set  and  invocation  to  GL  or  GR  overrides  the 
previous  invocation  to  the  GL  or  GR  respectively.  Thus  the  sequential  order  of  designation  and/or  invocation 
sequences  in  the  attribute  "graphic  character  sets"  is  significant. 


[B-bits  code  table] 


_  J  GL 


— I  

J  GR 


Empty  set 


_  J 


The   IRV  of    ISO  546 
revised  1991  CISO-IR63 


Empty  set 


[ I nvocat  i  onj 


G3 


[ Des  i  gnat  i  on] 


Figure  19  —  Code  extension  features  (basic  case) 


6.5.1.5  Line  spacing 

Any  value  of  line  spacing  may  be  specified.  Values  of  100.  150.  200.  300,  400  and  600  BMUs  are 
basic;  the  use  of  any  other  value  in  a  document  is  non-basic  and  shall  be  indicated  in  the  document 
profile. 

The  line  spacing  may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic  component 
using  the  presentation  attribute  "line  spacing".  The  value  may  be  changed  anywhere  within  the  content 
portion  using  the  control  functions  select  line  spacing  (SVS)  and  set  line  spacing  (SLS). 


6.5.1.6  Character  spacing 

Any  value  of  character  spacing  may  be  specified  as  basic  values. 

The  character  spacing  may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic 
component  using  the  attribute  "character  spacing".  The  value  may  be  changed  anywhere  within  a 
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[a-bits  code  table] 


nvocat  i  on] 


_  J 


The  IRV  of   ISO  646  revised  1991 
CIS0-IR6D^  the  primary  set  of  ISO 
6937-2  or  a  version  of   ISO  646. 


[ Des  i  gnat  i  on] 


Any  registered  graphic 
character  set 


Figure  20  —  Code  extension  features  (all  possible  cases) 

content  portion  using  the  control  functions  select  character  spacing  (SHS)  or  set  character  spacing 
(SCS). 


NOTE  23  -  SHS  parameters  of  0.  1 ,  2,  3  and  4  are  currently  provided.  Tfie  use  of  parameters  5  and  6  may  be 
provided  in  a  future  edition  of  this  profile  for  use  with  Chinese  characters. 


6.5.1.7  Character  path  and  line  progression 

Both  horizontal  and  vertical  writing  directions  may  be  used  within  a  document.  In  the  case  of  horizontal 
writing,  the  characters  progress  either  from  left  to  right  or  from  right  to  left  across  the  page  and  the  line 
progression  is  from  the  top  of  the  page  to  the  bottom.  In  the  case  of  vertical  writing,  the  characters 
progress  from  the  top  of  the  page  to  the  bottom  and  the  line  progression  is  from  the  right  to  the  left. 
The  use  of  these  writing  directions  is  restricted  by  the  page  layout  type  used. 

For  body  layout  A,  only  horizontal  writing  may  be  used  in  the  tx)dy  area.  Thus  the  character  path  and 
line  progression  is  specified  either  as  0  and  270  degrees  respectively  or  180  and  90  degrees 
respectively. 

For  body  layout  B.  again  only  horizontal  writing  may  be  used  in  the  body  area.  However,  in  this  case 
the  content  in  the  body  area  is  presented  for  viewing  with  the  page  in  landscape  orientation  and  the 
content  in  the  header  and  footer  areas  is  presented  for  viewing  with  the  page  in  portrait  orientation. 
Thus  for  body  layout  B,  in  the  body  area  the  character  path  and  line  progression  is  specified  either  as 
90  and  270  degrees  respectively  or  270  and  90  degrees  respectively. 


77 


For  body  layout  C.  only  vertical  writing  may  be  used  in  the  body  area.    Thus  the  character  path  and 
line  progression  are  specified  as  270  and  270  degrees  respectively. 

With  regard  to  the  header  and  footer  areas,  if  these  areas  are  placed  above  and  below  the  t)ody  area, 
as  shown  in  figure  1 ,  then  only  horizontal  writing  is  allowed  in  these  areas.  Thus,  in  this  case,  the 
character  path  and  line  progression  is  specified  either  as  0  and  270  degrees  respectively  or  180  and  90 
degrees  respectively  (see  figure  2). 

If  the  header  and  footer  areas  are  placed  to  the  left  and  right  of  the  body  area,  then  only  vertical  writing 
is  allowed  in  these  areas.  Thus,  in  this  case,  the  character  path  and  line  progression  are  specified  as 
270  and  270  degrees  respectively  (see  figure  4). 

All  values  of  character  path  and  line  progression  are  basic.  The  values  of  character  path  and  line 
progression  may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic  component  using 
the  presentation  attributes  "character  path"  and  "line  progression"  respectively.  These  values  cannot  be 
changed  within  a  content  portion. 


6.5.1.8  Character  positioning  controls 

The  active  position  of  a  character  (as  defined  in  (CCITT  Recommendation  T.416  |  ISO  8613-6])  can  be 
moved  fonward  or  backward  along  the  direction  of  the  line  progression  using  the  control  functions  line 
position  backward  (VPB)  and  line  position  relative  (VPR).  These  control  functions  may  be  specified  in 
all  forms  of  character  content,  and  any  parameter  value  may  be  specified. 

The  active  position  of  a  character  can  be  moved  forward  or  backward  along  the  direction  of  the 
character  path  using  the  control  functions  character  position  backward  (HPB)  and  character  position 
relative  (HPR). 

The  spacing  between  characters  can  be  increased  or  decreased  using  the  control  functions  set 
additional  character  spacing  (SACS)  and  set  reduced  character  spacing  (SRCS)  respectively.  Also,  the 
width  of  the  character  SPACE  can  be  set  using  the  control  function  set  SPACE  width  (SSW). 

The  control  functions  HPB,  HPR,  SACS.  SRCS  and  SSW  shall  only  be  specified  in  formatted  or 
formatted  processable  character  content;  any  parameter  value  may  be  specified. 


6.5.1.9  Character  orientation 

The  character  orientation  may  be  specified  as  0.  90,  180  or  270  degrees. 

The  orientations  of  0,  90,  and  180  degrees  are  usually  applied  depending  on  whether  vertical  or 
horizontal  writing  is  used.  When  horizontal  writing  is  used,  characters  may  only  be  orientated  at  0 
degrees.  When  vertical  writing  is  used,  characters  may  t>e  orientated  at  90  or  180  degrees. 

All  values  of  character  orientation  are  basic.  The  value  of  the  character  orientation  is  specified  at  the 
beginning  of  the  content  associated  with  a  basic  component  by  the  presentation  attribute  "character 
orientation".  This  value  cannot  be  changed  within  the  content. 


6.5.1.10  Graphic  character  composition 

A  string  of  two  or  more  characters  may  be  combined  to  form  a  single  character  using  the  control 
function  graphic  character  composition  (GCC).  Parameter  values  0,  1  and  2  may  be  specified. 
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6.5.1.11  Emphasis 

The  following  modes  of  empfiasising  grapfiic  characters  may  be  distinguished: 

—  normal  rendition; 

—  normal  intensity; 

—  increased  intensity  (bold); 

—  italicized; 

i      —  not  italicized; 

'I 

l|      —  underlined; 

—  doubly  underlined; 

—  not  underlined; 

—  crossed-out; 

—  not  crossed-out; 

—  slowly  blinking; 

I       —  rapidly  blinking; 

j       —  not  blinking; 

I 

—  negative  image; 
j       —  positive  image. 

I  All  the  above  modes  of  emphasis  are  basic.  If  no  default  mode  is  explicitly  specified  in  the  document 
Ij  profile,  then  the  default  mode  is  normal  rendition. 

I  The  mode  of  emphasis  may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic 
component  using  the  presentation  attribute  "graphic  rendition".  The  mode  may  be  changed  anywhere 
within  the  content  using  the  control  function  set  graphic  rendition  (SGR). 

The  mode  of  emphasis  remains  in  effect  within  the  content  associated  with  a  basic  component  until 
changed  into  a  mutually  exclusive  mode  or  by  the  specification  of  normal  rendition".  Mutually 
exclusive  nrodes  are  normal/increased/decreased  intensity,  not/slowly/rapidly  blinking,  italicized/not 
italicized,  underlined/doubly  underlined/not  underlined,  crossed-out/not  crossed-out  and 
positive/negative  image.  One  mode  from  each  mutually  exclusive  set  may  be  in  operation  at  any  point 
in  the  document  content. 

j 
i 

Normal  rendition  cancels  the  effect  of  all  modes  of  emphasis  that  are  currently  in  operation  and 
specifies  that  the  text  shall  be  displayed  in  accordance  with  the  default  rendition  parameters  set  for  the 
presentation  device.  Thus,  for  example,  if  it  is  required  to  ensure  that  the  content  is  not  underlined, 
then  it  is  necessary  to  explicitly  specify  that  underlined  is  not  to  be  used. 
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6.5.1.12  Tabulation 


Tabulatbn  stop  positions  may  be  specified  at  any  position  along  the  character  path.  Each  stop  is 
specified  by  means  of  the  following: 

a)  The  tabulation  position  relative  to  the  position  of  that  margin  in  the  direction  opposite  to 
the  character  path; 

b)  An  optional  alignment  qualifier  that  specifies  the  type  of  alignment  to  be  used  at  the 
designated  tabulation  position.  The  type  may  be  specified  as  one  of  the  following: 

1)  start  aligned; 

2)  end  aligned; 

3)  centred; 

4)  aligned  around. 

These  alignment  qualifiers  are  defined  in  (CCITT  Recommendation  T.416  |  ISO  8613-6].  If  the 
alignment  qualifier  is  not  explicitly  specified,  then  it  is  assumed  that  start  aligned  is  to  be  used. 

Only  one  set  of  tabulation  stops  may  be  specified  to  be  applicable  to  the  content  associated  with  a 
basic  component.  No  limit  is  placed  on  the  number  of  tabulation  stops  that  may  be  specified  within  a 
given  set. 

The  set  of  tabulation  stop  positions  associated  with  the  content  of  a  basic  component  are  specified 
using  the  presentation  attribute  "line  layout  table".  Tabulation  stop  positions  are  invoked  within  the 
content  using  the  control  function  selective  tabulation  (STAB). 

The  tabulation  reference  numbers  used  in  the  STAB  controls  and  associated  Line  Layout  Table  shall  be 
chosen  so  that  in  a  given  Line  Layout  Table,  the  reference  numbers  are  unique,  sequential  in  the 
direction  of  the  character  path,  and  do  not  include  leading  zeroes. 

6.5.1.13  Indentation 

Indentation  is  the  distance  between  the  first  character  on  a  line  of  content  and  the  position  of  the 
margin  that  is  in  the  direction  opposite  to  the  character  path.  Thus  the  value  of  the  indentation 
specified  determines  the  line  home  position  (as  defined  in  (CCITT  Recommendation  T.416  ( ISO 
8613-6]). 

Indentation  is  an  offset  of  that  margin  that  is  in  the  direction  opposite  to  the  character  path.  When  text 
is  formatted,  it  is  intended  to  be  laid  out  between  the  indentation  position  and  the  margin  position  in  the 
direction  of  the  character  path. 

Any  value  of  indentation  may  be  specified  for  basic  logical  components  using  the  presentation  attribute 
"indentation".  The  indentation  value  shall  not  be  changed  within  a  content  portion. 


6.5.1.14  Alignment 

This  feature  is  concerned  with  how  the  first  and  last  characters  on  each  line  of  character  content  Is  to 
be  laid  out  during  the  formatting  process. 

The  following  values  of  alignment  may  be  specified  as  basic: 
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—  start  aligned; 

—  end  aligned; 

—  centred; 

—  justified. 

The  semantics  of  ttiese  values  are  as  defined  in  [CCITT  Recommendation  T.416  |  ISO  8613-6]. 

The  presentation  attribute  "alignment"  is  used  to  specify  the  alignment  that  is  applicable  to  the  content 
associated  with  a  basic  component.  The  alignment  value  cannot  be  changed  within  a  content  portion. 


6.5.1.15  First  line  format 

This  feature  specifies  how  the  first  line  of  the  content  associated  with  a  basic  component  is  to  be  laid 
out  and  provides  for  the  itemization  of  paragraphs. 

It  allows  the  first  character  in  the  content  to  be  positioned  at  some  point  along  the  character  path 
relative  to  the  indentation  position  (as  specified  in  6.5.1.13).  This  point  may  be  in  the  direction  of  the 
character  path  or  in  the  direction  opposite  to  the  direction  of  the  character  path  relative  to  the 
indentation  position. 

I  In  addition,  this  feature  provides  for  the  specification  of  an  item  identifier  on  the  first  line.  The  item 
j  identifier  is  a  string  of  characters  that  precedes  and  is  separated  from  the  remaining  characters  that 
form  the  first  line.  The  control  function  carriage  return  (CR)  is  used  as  the  separator. 

9  The  features  provided  correspond  to  examples  10.1  to  10.5  shown  in  figure  10  of  [CCITT 
i  Recommendation  T.416  |  ISO  8613-6]. 

l|  First  line  format  is  specified  by  the  presentation  attributes  "first  line  offset",  "indentation"  and 
"itemization".  Only  those  values  of  the  attributes  which  combine  to  form  the  examples  shown  in  figure 
10  of  [CCITT  Recommendation  T.416  |  ISO  8613-6]  may  be  used. 


6.5.1.16  Widow  and  orphan  sizes 

The  widow  size  specifies  the  minimum  number  of  lines  of  content  that  shall  be  allocated  to  a  following 
frame  or  page  when  the  content  associated  with  a  basic  logical  component  is  laid  out  such  that  it  flows 
over  two  frames  or  pages.  To  accommodate  this,  it  may  be  necessary  to  move  a  number  of  lines  of 
content  from  one  frame  or  page  to  the  next  frame  or  page. 

The  orphan  size  specifies  the  minimum  number  of  lines  of  content  that  shall  be  placed  in  the  current 
frame  or  page  when  the  content  associated  with  a  basic  logical  component  is  split  over  two  frames  or 
pages.  If  this  minimum  cannot  be  accommodated,  then  the  whole  content  shall  be  placed  in  the  next 
frame  or  page. 

Any  value  of  widow  or  orphan  size  may  be  specified  using  the  presentation  attributes  "widow  size"  and 
"orphan  size"  respectively. 

Widow  and  orphan  size  shall  only  be  specified  for  character  content  placed  in  the  body  area  of  pages. 
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6.5.1.17  Fonts 

Any  number  of  fonts  may  be  used  within  a  document  The  fonts  used  in  a  particular  document  are 
specified  in  the  document  profile  using  the  attribute  "fonts  list". 

Further  information  concerning  the  specification  of  font  references  in  the  document  profile  is  given  in 
Annex  B.2. 

The  fonts  that  may  be  used  within  the  content  associated  with  each  basic  component  are  specified  by 
the  presentation  attribute  "character  fonts".  Up  to  10  fonts  taken  from  the  list  specified  by  the  attribute 
"fonts  list"  may  be  specified  by  the  attribute  "character  fonts". 

The  font  to  be  used  at  the  start  of  the  content  associated  with  a  basic  component  is  specified  using  the 
attribute  "graphic  rendition".  The  fonts  used  within  the  content  may  be  changed  using  the  control 
function  set  graphic  rendition  (SGR). 

The  document  profile  may  specify,  using  the  attribute  "character  fonts",  a  default  set  of  up  to  10  fonts 
that  are  applicable  to  the  whole  document. 

6.5.1.18  Reverse  character  strings 

Bi-directional  writing  is  supported  by  this  profile.  Hence,  a  string  of  characters  in  a  content  portion 
associated  with  a  basic  component  may  be  specified  to  be  imaged  in  the  reverse  direction  of  the 
immediately  preceding  character  string.  Such  strings  may  be  specified  by  the  control  function  start 
reverse  string  (SRS)  as  defined  in  [CCITT  Recommendation  T.416  |  ISO  8613-6]. 

This  control  function  is  provided  for  cases  in  which  the  text  belongs  to  different  languages  and  the 
character  content  is  written,  for  example,  from  left  to  right  or  from  right  to  left  within  the  same  line  of 
characters,  dependent  upon  the  language  and/or  character  set  being  used. 


6.5.1.19  Parallel  text 

A  string  of  characters  in  a  content  portion  associated  with  a  basic  component  may  be  specified  to  be 
imaged  in  parallel  with  another  character  string.  Typical  example  is  "ruby"  in  the  Japanese  language. 

In  processable  and  formatted  processable  content,  parallel  text  may  be  specified  by  the  control  function 
parallel  text  (PTX). 

In  formatted  content,  the  control  functions  character  position  relative  (HPR),  character  position 
backward  (HPS),  line  position  relative  (VPR)  and  line  position  backward  (VPS)  may  be  used  to  specify 
parallel  text.  These  control  functions  may  also  be  present  in  formatted  processable  content  provided 
that  they  are  contained  within  strings  delimited  by  the  control  functions  start  of  string  (SOS)  and  string 
terminator  (ST). 


6.5.1.20  Kerning  offset 

A  kerning  offset  value  for  the  content  associated  with  a  basic  component  may  be  specified  using  the 
presentation  attribute  "kerning  offset".  It  is  necessary  to  specify  such  a  value  when  certain  fonts  are 
invoked  to  ensure  that  no  part  of  character  images  are  positioned  outside  the  tx)undary  of  the  available 
area. 
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6.5.1.21  Pairwise  kerning 


Pairwise  kerning  may  be  specified  to  take  place  during  the  layout  process  using  the  attribute  "pairwise 
kerning".  This  process  depends  upon  the  font  used  and  the  modification  applied  to  the  positions  of 
characters  depends  on  the  kerning  information  in  the  font  attributes.  Painwise  kerning  shall  only  be 
carried  out  if  a  variably  spaced  font  is  used;  the  attribute  "pairwise  kerning"  is  ignored  if  a  constant 
spaced  font  is  used. 


>  6.5.1.22  Proportional  line  spacing 

The  use  of  proportional  line  spacing  may  be  invoked  for  the  content  associated  with  a  basic  logical 
i*  component  using  the  attribute  "proportional  line  spacing".  When  this  invocation  occurs,  the  line  spacing 
i  between  each  pair  of  consecutive  lines  is  determined  in  an  implementation-defined  way  from  the 
i  attributes  associated  with  the  fonts  used  within  the  two  lines  and  may  vary  from  one  line  to  the  next. 

This  process  is  application  dependent. 


6.5.1.23  Superscripts  and  subscripts 

Superscripts  and  subscripts  may  be  specified  anywhere  within  the  content  associated  with  a  basic 
component  by  using  the  control  functions  partial  line  up  (PLU)  and  partial  line  down  (PLD).  The  use  of 
these  control  functions  shall  be  in  accordance  with  [CCITT  Recommendation  T.416  |  ISO  8613-6]. 


6.5.1.24  Line  breaks 

I  The  control  functions  break  permitted  here  (BPH)  and  no  break  here  (NBH)  may  be  inserted  in 

j  processable  or  formatted  processable  form  character  content  to  indicate  where  line  breaks  may  occur 

I  or  may  not  occur  respectively  when  the  content  is  laid  out. 

j| 

<  6.5.1.25  Substitution  characters 

ij 

I  The  control  function  SUB  is  provided  to  represent  characters  produced  by  a  local  system  that  cannot  be 
I  represented  by  a  character  within  a  character  set  supported  by  this  profile. 

6.5.1.26  Initial  point 

The  initial  point  which  is  applicable  to  basic  layout  components  may  be  specified  by  the  attribute  "initial 
i  offset".  Any  value  may  be  specified. 


6.5.1.27  Use  Of  control  functions 

The  following  is  a  list  of  all  the  control  functions  and  parameter  values  (where  applicable)  that  may  be 
specified  in  character  content; 

SHS  —  select  character  spacing  (allowed  parameter  values:  0,  1,2,  3,  4); 

SCS  —  set  character  spacing  (allowed  parameter  values:  any); 

SVS  —  select  line  spacing  (allowed  parameter  values:  any), 
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SLS  —  set  line  spacing  (altowed  parameter  values:  any);  ' 

SGR  —  set  graphic  rendition  (allowed  parameter  values:  any); 

STAB—  selective  tabulation  (allowed  parameter  values:  any): 

SRS  —  start  reverse  string  (allowed  parameter  values:  any); 

GCC  —  graphic  character  composition  (allowed  parameter  values:  any); 

IGS  —  identify  graphic  subrepertoire  (allowed  parameter  values:  any); 

VPB  —  line  position  backward  (allowed  parameter  values:  any);  | 

VPR  —  line  position  relative  (allowed  parameter  values:  any); 

HPS  —  character  position  backward  (altowed  parameter  values:  any); 

HPR  —  character  position  relative  (allowed  parameter  values:  any); 

SACS—  set  addit tonal  character  spacing  (allowed  parameter  values:  any); 

SRCS—  set  reduced  character  spacing  (allowed  parameter  values:  any); 

SSW  —  set  SPACE  width  (allowed  parameter  values:  any); 

PTX  —  parallel  text; 

PLD  —  partial  line  down; 

PLU  —  partial  line  up;  1 
BPH  —  break  permitted  here; 

NBH  —  no  break  here;  j 
JFY  —  no  justify; 

SUB  —  substitute  character;  ^ 
SP  —  space;  j 
CR    —  carriage  return; 

■  i 

LF    —  line  feed; 

s 

SOS  —  start  of  string; 

ST    —  string  terminator; 

—  code  extenston  control  functions  (see  6.5.1 .4). 

The  use  of  all  these  control  functtons.  with  the  exceptton  of  SP.  CR,  LF.  SOS  and  ST,  are  described  in  ^; 
various  subclauses  in  6.5.1. 
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6.5.1.28  Formatting  the  content 


The  attribute  "formatting  indicator"  may  be  specified  for  particular  basic  objects  ttiat  are  conformant  with 
this  profile. 

The  effect  is  to  provide  for  transmission  of  formatted  (or  formatted  processable)  objects  for  which  the 
precise  placement  of  individual  characters  has  been  fully  computed,  and  all  necessary  control  functions 
included.  The  implication  is  that  most  operations  normally  performed  by  the  imaging  processing  in 
handling  formatted  character  text  will  be  rendered  unnecessary. 

To  make  use  of  this,  the  imaging  process  of  the  recipient  shall  operate  with  a  font  containing  metrics 
identical  to  that  used  by  the  originator. 


6.5.2  Raster  graphics  content 


6.5.2.1  introduction 

This  sutxiause  defines  the  features  that  are  applicable  to  the  raster  graphics  content  contained  in  a 
document.  These  features  may  apply  to  basic  logical  and  layout  components  unless  otherwise 
indicated. 

The  default  values  for  the  following  features  may  be  specified  in  the  document  profile: 

—  type  of  coding; 

—  compression; 

—  pel  spacing; 

—  spacing  ratio; 

—  clipping; 

—  image  dimensions; 

—  pel  path; 

—  line  progression. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation  or  coding  attribute  or  control 
function  shall  be  indicated  in  the  document  profile. 


6.5.2.2  Raster  graphics  content  architecture 

Only  the  formatted  processable  raster  graphics  content  architecture  class  may  be  used  in  docunr)ents 
that  conform  to  this  document  application  profile.  This  type  of  content  may  be  used  in  processable, 
formatted  and  fomiatted  processable  form  documents. 

When  using  raster  graphics  content,  only  one  content  portion  may  be  associated  with  an  object  or 
object  class. 
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The  content  information  in  a  content  portion  nnay  be  absent.  This  is  to  allow  the  representation  and 
interchange  of  documents  in  which  parts  of  the  content  may  be  supplied,  for  example,  duhng 
subsequent  editing. 

Also,  the  scalable  or  fixed  dimension  content  layout  process  may  be  used  when  laying  out  and  imaging 
the  content  depending  upon  the  specification  of  the  presentation  attributes  "pel  spacing"  and  "imaging 
dimensions"  as  described  in  6.5.2.6  and  6.5.2.8.  Both  forms  of  content  layout  processes  may  be  used 
in  a  single  document. 


6.5.2.3  Raster  graphics  encoding  methods 

The  content  may  be  encoded  in  accordance  with  the  encoding  schemes  defined  in  CCITT 
Recommendations  T.4  and  T.6.  In  the  case  of  T.4,  either  the  one-dimensional  or  two  dimensional 
encoding  scheme  may  be  used.  Also  the  'bit-map  encoding'  scheme  defined  in  (CCITT 
Recommendation  T.417  |  ISO  8613-7]  may  be  used.  All  these  forms  of  encoding  may  be  used  in  a 
single  document,  and  all  are  basic.  'Uncompressed'  nnode  of  encoding  may  also  be  used,  but  as  a 
non-basic  feature. 

When  using  the  T.4  or  T.6  encoding  method,  the  relationship  between  the  order  of  pels  and  the  order 
of  bits  in  the  octets  in  the  coded  data  stream  shall  be  such  that  the  first  pel  in  the  order  of  bits  is 
allocated  to  the  least  significant  bit  of  an  octet.  In  the  case  of  bit-map  encoding,  the  order  of  encoding 
shall  be  that  the  first  pel  is  allocated  to  the  most  significant  bit  of  an  octet. 

In  a  content  portion,  if  content  information  is  specified,  it  is  required  that  the  coding  attribute  "number 
of  pels  per  line"  is  specified;  the  coding  attribute  "number  of  lines"  may  also  be  specified.  No  restriction 
is  placed  on  the  values  that  may  be  specified  for  these  coding  attributes.  Thus  this  profile  places  no 
restriction  on  the  size  of  the  pel  arrays  that  may  be  used. 

The  type  of  encoding  method  used  is  specified  by  the  attribute  "type  of  coding".  The  use  of  this 
attribute  is  non-mandatory.  Thus,  if  this  attribute  is  not  specified  for  a  particular  content  portion  and  if 
the  content  architecture  class  specified  corresponds  to  the  formatted  processable  raster  graphics 
content  architecture  class,  then  the  default  encoding  method  is  assumed  to  be  T.6. 


6.5.2.4  Pel  path  and  line  progression 

The  pel  path  direction  may  be  specified  as  0.  90,  180  or  270  degrees  The  line  progression  direction 
may  be  specified  as  90  or  270  degrees. 

A  pel  path  of  0  degrees  and  a  line  progression  of  270  degrees  are  basic  values.  All  other  values  are 
non-basic  and  their  use  shall  be  indicated  in  the  document  profile 

6.5.2.5  Clipping 

A  sub-region  within  a  pel  array  represented  by  a  content  portion  associated  with  a  basic  component 
may  be  defined  using  the  presentation  attribute  "clipping".  No  restriction  is  placed  on  the  use  of  this 
attribute. 


6.5.2.6  Pel  spacing 

The  pel  spacing  is  the  distance  in  SMUs  between  any  two  pels  on  a  line  when  a  pel  array  is  imaged. 
Any  value  may  be  explicitly  specified  provided  that  the  spacing  between  pels  is  not  less  than  1  SMU. 
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The  pel  spacing  need  not  be  an  integer  value.  Also,  the  value  'null'  may  be  specified,  indicating  that 
the  scalable  layout  process  is  to  be  used. 

The  specification  of  the  value  null'  or  spacings  of  16,  12,  8,  6.  5,  4,  3,  2,  and  1  Sf^U  between  adjacent 
pels  are  basic.  The  specification  of  any  other  spacing  is  non-basic  and  shall  be  indicated  in  the 
document  profile. 

The  pel  spacing  applicable  to  content  associated  with  basic  logical  components  is  specified  by  the 
presentation  attribute  "pel  spacing". 

NOTE  24  -  The  basic  pel  spacing  values  listed  above  are  equivalent  to  resolutions  of  75,  100,  150,  200,  240, 
300,  400,  600  and  1200  pels  per  25.4mm  respectively  when  the  SMU  is  interpreted  as  1/1200  inch. 

NOTE  25  -  The  attribute  "pel  spacing"  specifies  two  integers,  the  ratio  of  which  determines  the  pels  spacing. 
No  restriction  is  placed  on  the  values  of  these  integers. 


6.5.2.7  Spacing  ratio 

The  spacing  ratio  is  the  ratio  between  the  pel  spacing  and  the  line  spacing  when  a  pel  array  is  imaged. 
This  ratio  is  used  to  determine  the  line  spacing  from  the  pel  spacing  specified. 

No  restrictions  are  placed  on  the  value  of  this  ratio  providing  that  the  resultant  line  spacing  is  not  less 
than  1  SMU.  Also,  the  line  spacing  need  not  be  an  integral  number  of  SMUs.  All  values  are  basic. 

The  default  value  may  be  specified  in  the  document  profile.  If  no  default  value  is  explicitly  specified 
then  the  default  value  is  the  ratio  1:1,  that  is,  the  line  spacing  is  equal  to  the  pel  spacing. 

The  spacing  ratio  applicable  to  the  content  associated  with  a  basic  logical  component  is  specified  by 
the  presentation  attribute  "spacing  ratio". 


6.5.2.8  Image  dimensions 

The  image  dimensions  are  the  constraints  to  be  applied  to  the  size  of  the  image  produced  when  laying 
out  a  pel  array  represented  by  a  content  portion  associated  with  a  basic  logical  component. 

These  constraints  are  specified  for  basic  logical  components  by  the  presentation  attribute  "image 
dimensions".  The  value  of  this  attribute  is  only  taken  into  account  if  the  value  of  the  attribute  "pel 
spacing"  is  'null'. 


6.5.3  Geometric  grapliics  content 

A  document  may  contain  graphic  images  composed  of  geometric  graphic  content  encoded  as  CGM 
metafiles  in  accordance  with  ISO  8632.  Each  CGM  figure  shall  consist  of  a  single  picture  only.  Each 
CGM  figure  may  specify  its  minimum  dimensions. 


6.6  Miscellaneous  features 
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6.6.1  Resource  documents 

Object  classes  of  the  types  BodyText,  BodyRaster,  BodyGeometric,  CommonText,  CommonRaster, 
CommonGeometric.  EntryText.  EntryRaster,  EntryGeometric  and  GenericBlock  may  refer  to 
corresponding  constituent  constraints  in  a  resource  generic-document. 

The  constituent  constraints  in  the  resource  document  may  refer  to  content  portions  and  to  layout  and 
presentation  styles  that  are  contained  within  the  resource  document.  The  constituent  constraints  listed 
above  are  the  only  ones  that  are  allowed  to  be  referenced  from  another  document  via  the  resource 
attribute;  however,  generic-documents  used  as  resource  documents  may  contain  any  combination  of 
generic  constituent  constraints  which  is  conformant  to  this  document  application  profile. 


6.6.2  External  documents 

In  the  case  of  processable  and  formatted  processable.  the  generic  logical  structure  and  the  generic 
layout  stnjcture,  if  present,  may  be  contained  in  an  external  document.  Note  that  it  is  not  permitted  to 
exchange  one  generic  structure  in  the  interchanged  document  while  referencing  the  other  through  the 
external  document. 


6.6.3  Border 

Borders  may  be  specified  for  all  the  frame  types  defined  in  6.3.5  and  6.3.6  using  the  attribute  "twrder". 
All  the  features  of  borders  specified  in  (CCITT  Recommendation  T.412  |  ISO  8613-2]  may  be  specified 
as  basic  values.  Borders  may  also  be  specified  in  presentation  styles. 


6.6.4  Unit  scaling 

The  document  profile  attribute  "unit  scaling"  may  be  specified  to  indicate  a  scaling  factor  that  shall  be 
applied  to  all  attributes  and  control  functions  values  that  specify  absolute  or  relative  positions  and 
dimensions.  This  attribute  specifies  two  integers,  m  and  n,  which  indicate  that  these  values  are  to  be 
interpreted  as  being  equal  to  m/n  ML). 


6.6.5  Application  comments 

Specification  of  the  attribute  "application  comments"  is  mandatory  for  all  object  classes  contained  in  a 
document  that  conforms  to  this  profile.  Specification  and  use  of  this  attribute  is  optional. 

This  attribute  is  structured  so  that  it  contains  two  fields.  The  first  field  is  mandatory  when  the  attribute 
is  specified  and  contains  a  numeric  string  which  uniquely  identifies  the  constituent  constraint  applicable 
to  the  constituent  for  which  the  attribute  is  specified.  This  facilitates  the  processing  of  documents.  A 
list  of  these  identifiers  is  given  in  table  5  and  6. 

NOTE  26  . 

a)  The  values  of  the  constituent  constraint  numeric  identifiers  are  not  unique  between  the 
logical  and  layout  structures,  and  therefore  in  order  to  Identify  the  constituent  constraint 
applicable  to  a  constituent,  it  is  necessary  to  know  the  structure  of  which  the  constituent 
is  a  part. 
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b)  For  constituent  constraints  that  correspond  to  each  other  between  the  hierarchically 
related  profiles  to  which  this  profile  belongs,  the  same  constituent  constraint  numeric 
identifier  is  specified. 


'The  second  field  is  optional  and  may  contain  any  information  that  is  relevant  to  the  application  or  user. 
jThe  format  of  the  second  field  is  not  defined  in  this  profile  and  the  interpretation  of  this  field  depends 
upon  a  private  agreement  between  the  originator  and  recipient  of  the  document 

The  encoding  of  the  attribute  "application  comments"  is  defined  in  8.1.3  and  8.2.3. 


L6.6  Alternative  representation 

The  content  information  in  a  content  portion  may  be  replaced  by  a  string  of  characters  specified  in  the 
attribute  "Alternative  representation".  This  attribute  may  be  specified  in  content  portions  that  contain 
;haracter,  raster  graphics  or  geometric  graphics  content. 

'The  specification  and  use  of  this  attribute  is  optional.  The  string  of  characters  specified  shall  belong  to 
the  character  repertoires  indicated  in  the  document  profile  attribute  "alternative  representation  character 
sets"  (see  6.7.4.3).  If  the  latter  attribute  is  not  explicitly  specified  in  the  document  profile,  then  the 
default  defined  in  [CCITT  Recommendation  T.410  series  |  ISO  8613]  is  assumed.  The  control  functions 
space  (SP),  carriage  retum  (CR)  and  line  feed  (LF)  may  also  be  used  within  the  character  string  but  no 
other  control  function  is  allowed;  hence  graphic  character  sets  cannot  be  changed  within  the  alternative 
representation. 


6.6.7  Automatic  numbering  and  referencing  mechanisms 


6.6.7.1  Introduction 

This  profile  provides  general  mechanisms  to  support  the  automatic  numbering  of  various  types  of 
constituents  in  a  document  and  for  referencing  those  numbers  from  other  constituents  in  the  document. 
For  example,  the  numbering  of  segments  (such  as  chapters,  sections  and  annexes),  tables,  figures, 
footnotes,  lists  of  items  and  pages  is  supported. 

Also  character  strings  may  be  specified  for  various  constituents  and  these  strings  may  be  referenced 
from  other  parts  of  a  document  in  order  to  support  a  general  referencing  mechanism  within  a 
document. 

To  achieve  these  features,  this  profile  provides  the  bindings  listed  in  6.6.7.2.  Sut)clauses  6.6.7.3  to 
6.6.7.11  describe  how  these  bindings  are  used  in  the  automatic  numbering  and  referencing  schemes. 
These  descriptions  are  not  intended  to  restrict  the  use  of  the  bindings  provided  by  this  profile  or  the 
mechanisms  used  to  achieve  these  numbering  and  referencing  schemes. 

6.6.7.2  Bindings 

The  binding  listed  below  may  be  specified,  unless  othenwise  stated,  on  any  composite  logical 
constituent,  on  basic  logical  constituent  constraints  of  the  types  BodyText,  BodyRaster  and 
BodyGeometric  and  on  layout  constituent  constraints  of  the  types  DocumentLayoutRoot,  PageSet, 
Page,  RectoPage  and  VersoPage. 
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I 

Table  5  —  List  of  number  string  identifiers  for  logical  constituents 


Logical  constituent 

Numeric  s 

identifier 

DocumentLogicalRoot 

0 

Passage 

1 

NumberedSegment 

2 

Number 

3 

Title 

4 

Caption 

5 

Paragraph 

6 

Phrase 

7 

Footnote 

8 

FootnoteNumber 

9 

FootnoteReference 

10 

FootnoteBody 

11 

FootnoteText 

12 

Figure 

13 

BodyText 

14 

Reference 

15 

ReferencedContent 

16 

Body  Raster 

17 

BodyGeometric 

18 

CommonContent 

19 

CommonText 

20 

CommonRaster 

21 

CommonGeometric 

22 

Description 

23 

Artwork 

24 

NumberedList 

25 

UnNumberedList 

26 

DefinitionList 

27 

Listltem 

28 

ListTerm 

29 

Table 

30 

Row 

31 

TableComponent 

32 

RowComponent 

33 

Form 

34 

EntryElement 

35 

EntryGroup 

36 

CommonReference 

37 

CommonNumber 

38 

Currentlnstance 

39 

PageNumber 

40 

Entry  Text 

41 

EntryRaster 

42 

Entry  Geometric 

43 

TableNumber 

44 

Groups  of  bindings  tiave  names  wliose  general  form  is  '<name>-<n>'.  The  character  string  <name> 
serves  to  identify  a  particular  group  of  bindings  and  <n>  is  a  string  of  characters  that  serves  to  identify 
a  particular  binding.  The  field  <n>  is  a  sequence  of  characters  taken  from  the  set  of  characters  '0..9"; 
this  sequence  may  be  of  any  length,  but  shall  consist  of  a  string  representing  an  integer  with  no  leading 
zeroes. 
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Table  6  —  List  of  number  string  identifiers  for  layout  constituents 


Layout  constituent  Numeric  string 

identifier 

DocumentLayoutRoot  o 

PageSet  1 

Page  2 

RectoPage  3 

VersoPage  4 

CompositeHeader  5 

FixedCompositeBody  6 

VariableCompositeBody  7 

ColumnFixed  8 

ColumnVariable  9 

SnakingColumns  10 

SynchronizedColumns  11 

BasicFloat  12 

CompositeFloat  13 

BasicColumn  14 

Footnote  Area  15 

ArrangedContentFixed  16 

ArrangedContentVariable  17 

SourcedContentFixed  18 

SourcedContentVariable  19 

CompositeFixtureVariable  20 

CompositeFixtureFixed  21 

BasicFixture  22 

CompositeColumnFixed  23 

CompositeColumnVariable  24 

CompositeCommon  25 

CompositeArtwork  26 

BasicHeader  27 

BasicBody  28 

GenericBlock  29 

SpecificBlock  30 

FormArea  31 

CompositeFooter  32 

BasicFooter  33 

TableHeader  34 

EntryGroupArea  35 

TableArea  36 

TableLabel  37 

CompositeTableLabel  38 

LabelComponent  39 

RowArea  40 

Cell  41 

SubRowGroup  42 

SubRow  43 

TableLabelContent  44 

Form  Entry  Area  45 


Binding  values  may  consist  of  Integers  or  character  strings.  In  the  case  of  integers,  any  value  may  be 
specified.  In  the  case  of  character  strings,  the  string  may  consist  of  any  of  the  94  characters  of  the  IRV 
of  ISO  646  revised  1991 ,  IS0-IR6,  plus  the  character  space.  Any  other  character  repertoire  may  be 
used  provided  it  is  designated  and  Invoked  by  the  appropriate  designation  and  invocation  sequences, 
and  indicated  in  the  document  profile  as  a  non-basic  value.  No  other  control  functions  may  be  used. 
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6.6.7.2.1  Binding  'prefiKes-<n>' 

This  binding  specifies  a  character  string  that  is  typically  used  to  specify  a  prefix  string  in  a  character 
string  represented  by  another  binding.  Examples  are  prefixes  to  segment,  footnote  and  page  numbers. 


6.6.7.2.2  Binding  'suffixes-<n>' 

This  binding  specifies  a  character  string  that  is  typically  used  to  specify  a  suffix  string  in  a  character 
string  represented  by  another  binding.  Examples  are  suffixes  to  segment,  footnote  and  page  numbers. 


6.6.7.2.3  Binding  'numberstring-<n>' 

This  binding  specifies  a  character  string  that  typically  consists  of  one  or  more  numerals  and  separators 
that  constitutes,  for  example,  a  segment,  figure,  table,  list  item  or  footnote  number  in  a  document.  An 
example  is  the  string  '3.4.3.6'  which  might  identify  a  sub-section  in  a  document. 


6.6.7.2.4  Binding  'numbers-<n>' 

This  binding  specifies  an  integer  that  is  associated  with  a  particular  constituent.  This  integer  is  typically 
used  to  generate  a  numeral  or  a  sequence  of  numerals,  represented  by  the  binding  'numberstring-<n>' 
that  identifies,  for  example,  a  particular  segment,  footnote,  table,  figure,  list  item  or  page  within  a 
document. 

6.6.7.2.5  Binding  'separator-<n>' 

This  binding  specifies  a  character  string  that  is  typically  used  to  represent  the  separators  between 
numerals  in  a  string  represented  by  the  binding  'numberstring-<n>'.  An  example  is  the  string  '3.4.3.6' 
where  the  character '.'  forms  the  separator. 


6.6.7.2.6  Binding  'string-<n>' 

This  binding  specifies  a  character  string  that  is  associated  with  a  constituent  and  is  used  to  support  a 
general  referencing  mechanism  with  a  document.  Typically  this  binding  is  used  to  support  the 
referencing  of  character  content  specified  in  one  part  of  the  document  from  another  part  of  the 
document.  For  example,  this  binding  might  be  used  to  carry  the  title  of  a  chapter  or  figure  that  is 
referenced  in  some  other  part  of  the  document. 


6.6.7.2.7  Binding  'PGnum* 

This  binding  specifies  an  integer  that  typically  represents  a  page  number.  This  binding  may  only  be 
specified  on  layout  constituent  constraints  of  the  types  DocumentLayoutRoot,  PageSet,  RectoPage, 
VersoPage  and  Page. 
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{6.6.7.2.8  Binding  'fnotenumber' 

This  binding  specifies  an  integer  that  is  specifically  provided  to  represent  the  numbers  that  identify 
ll  footnotes.  This  binding  may  only  be  specified  for  the  logical  constituent  constraints 
'  DocumentLogicalRoot,  Passage  and  Footnote,  and  is  provided  for  compatibility  with  FOD26. 


1 6.6.7.2.9  Binding  fnotestring' 

This  binding  specifies  a  character  string  which  is  the  equivalent  of  the  number  represented  by  the 
binding  'fnotenumber'.  This  binding  may  only  be  specified  for  the  logical  constituent  constraint 
*  Footnote,  and  is  provided  for  compatibility  with  FOD26. 

i  6.6.7.3  Numbering  of  segments 

,  I  The  constituent  Number  contains  a  content  generator  which,  when  evaluated  during  the  layout  process, 
'^l  produces  a  character  string  that  serves  to  identify  the  NumberedSegment  to  which  the  constituent 
constraint  Number  belongs. 

The  format  of  this  character  string  is  as  follows: 

<pre-str><num-str><suf-str> 

I  This  format  is  defined  by  a  string  expression  which  is  specified  by  the  macro  SEGMENTNUMBER  (see 
7.3.1).  The  description  below  indicates  how  this  string  is  typically  generated. 

The  fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  character  strings  respectively  which  may 
be  of  any  length.  These  may  be  predefined  in  the  expression  or  derived  from  bindings  of  the  type 
'prefix-<n>'  and  'suffix -<n>'  respectively  that  are  defined  on  constituents  at  higher  levels  in  the 
document  structure. 

The  field  <num-str>  is  the  segment  identifier  which  has  the  following  general  form: 
<number>[<separator><number>]... 


where  [..]...  indicates  optional  repetition.  That  is,  a  segment  identifier  consists  of  a  single  numeral  or  a 
1  sequence  of  two  or  more  numerals,  each  of  which  is  separated  by  a  character  string  called  a 
jl  'separator'.  An  example  is  the  string  '7.3.3.1'. , 

I  Segment  identifiers  are  represented  by  the  binding  'numberstring-<n>'.  This  binding  may  be  explicitly 
I  specified  or  generated  automatically  by  a  sthng  expression  defined  by  the  macro 
USENUMBERSTRINGS  (see  7.3.1)  which  has  the  general  form: 

<numberstring-x><separator-y><number-z> 

The  field  <numberstring-x>  is  a  reference  to  the  segment  identifier  (that  is,  another  instance  of  a 
,  binding  of  the  type  'numbersthng-<n>')  that  is  specified  for  the  immediately  superior 
NumberedSegment.  This  allows  hierarchically  structured  numbering  schemes  to  be  specified.  If  this 
NumberedSegment  does  not  exist,  then  this  field  is  empty  and,  in  this  case,  non-hierarchical. 

The  field  <separator-y>  is  character  string  derived  from  a  binding  of  the  type  'separator-<n>'  specified 
at  some  higher  level  in  the  document  structure.  This  field  may  be  empty. 


93 


The  field  <number-z>  is  the  number  represented  in  the  form  of  a  character  string  that  is  applicable  to 
the  NumberedSegment  whose  identifier  is  being  constructed.  This  number  may  be  represented  in  the 
form  of  an  Arabic  numeral  string,  upper  or  lower  case  Roman  numeral  string  or  by  upper  or  lower  case 
alphabetic  characters. 

The  integer  value  corresponding  to  the  field  <number-z>  may  be  generated  by  one  of  two  methods. 
The  value  may  be  generated  by  a  ORDINAL  function  within  the  expression  defined  by  the  macro 
USENUMBERSTRINGS.  Alternatively,  It  may  be  derived  by  a  binding  of  the  type  ■number-<n>'  which  is 
specified  for  the  NumberedSegment  whose  identifier  is  being  constructed.  The  binding  'number-<n>'  is 
initialized  at  some  suitable  point  in  the  document  and  is  then  automatically  incremented  on  each 
successive  NumberedSegment.  This  is  achieved  using  an  expression  defined  by  the  macro 
USENUMBERS  (see  7.3.1). 

The  constructed  binding  ■numberstring-<n>'  generated  by  the  macro  USENUMBERSTRINGS  may  then 
be  referred  to  by  a  content  generator  specified  by  the  constituent  Number  to  generate  the  identifier  of 
the  NumberedSegment  as  indicated  earlier  in  this  subclause. 

This  binding  is  also  available  for  constaicting  the  segment  identifiers  used  at  lower  levels  of 
NumberedSegment.  This  means  that  a  hierarchical  numbering  scheme  may  be  specified  for  the 
NumberedSegments  at  different  levels  of  the  document  structure. 

The  level  number  shall  be  indicated  using  the  smallest  possible  number  of  characters,  that  is,  there 
shall  be  no  leading  zeroes. 

A  document  may  contain  any  number  of  different  independent  numbering  schemes.  This  is  achieved 
by  setting  the  value  of  bindings  of  the  type  'number-<n>',  ■numberstring-<n>.  'prefix-<n>'  and  suffix- 
<n>';  and  the  expressions  indicated  above  at  appropriate  points  in  the  document  structure. 

The  above  mechanism  may  be  used  for  different  purposes;  subsequent  subclauses  illustrate  how  this 
mechanism  is  typically  used  for  the  numbering  of  figures,  tables,  lists  of  items  and  footnotes. 


6.6.7.4  Numbering  of  figures 

The  mechanism  used  for  numbering  figures  is  the  same  as  that  used  for  numbering  segments  (see 
6.6.7.3).  That  is,  the  number  of  a  figure  is  generated  by  a  content  generator  specified  in  the  constituent 
Number  which  is  immediately  subordinate  to  the  given  Figure.  This  content  generator  contains  an 
expression  whose  value  is  defined  by  the  macro  SEGMENTNUMBER.  The  number  associated  with 
each  figure  may  be  represented  by  a  binding  of  the  type  ■number-<n>'  and  a  binding  'numberstring-<n>' 
is  used  to  specify  the  character  string  that  represents  the  figure  number.  The  generation  of  these 
bindings  is  as  described  in  6.6.7.3. 

The  figures  in  a  document  may  be  consecutively  numbered  throughout  the  document  irrespective  of  the 
part  of  the  document  in  which  the  figure  are  contained.  Alternatively,  the  numbers  may  be  linked  to  the 
part  of  the  document  to  which  they  relate;  for  example,  the  figures  in  chapter  3  of  a  document  can  be 
specified  as  3.1 ,  3.2,  3.3  and  so  on. 


6.6.7.5  Numbering  of  lists 

A  list  of  items  that  are  individually  numbered  is  represented  by  the  logical  constituent  NumberedList. 
Each  item  is  represented  by  a  constituent  constraint  of  the  type  Listltem  and  each  number  belonging  to 
each  item  is  represented  by  a  preceding  constituent  constraint  of  the  type  Number. 
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Number  contains  a  content  generator  which,  when  evaluated,  generates  the  number  belonging  to  the 
subsequent  item.  The  format  of  this  content  generator  is  the  same  as  that  used  for  numbering 
segments  (see  6.6.7.3)  and  is  defined  by  the  macro  SEGMENTNUMBER. 

As  described  in  6.6.7.3,  the  binding  'numberstring-<n>'  is  used  to  represent  the  number  string 
belonging  to  each  item.  In  this  case,  this  binding  is  generated  on  the  constituent  constraint  Numt)er 
which  is  referred  to  by  the  content  generator  contained  in  the  same  constituent  constraint.  (Note  that  in 
the  case  of  segment  numbers,  the  binding  'numberstring-<n>'  is  generated  on  the  superior  object.) 


6.6.7.6  Numbering  of  tables 

The  constituent  constraint,  TableNumber,  is  typically  used  to  represent  a  character  string  that 
constitutes  the  number  that  relates  to  a  Table.  This  string  is  laid  out  in  a  TableHeader  frame  by  means 
of  a  SourcedContentFixed  frame.  The  latter  frame  specifies  the  attribute  "logical  source"  which 
indicates  the  instance  of  the  constituent  constraint  ComnrKDnContent  that  contains  the  sut)ordinate 
TableNumber  which  specifies  the  required  table  number. 

The  character  string  represented  by  TableNumber  is  generated  by  a  content  generator  which  defines  a 
string  expression  specified  by  the  macro  TABLENUMBER  (see  7.3.1).  The  general  format  of  this 
character  string  is  as  follows: 

<pre-str><num-str><suf-str> 

The  fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  character  strings  which  are  pre-defined 
in  the  expression  or  are  derived  from  bindings  of  the  types  'prefix-<n>'  and  'suffix-<n>'  respectively  that 
are  specified  for  constituents  at  higher  levels  in  the  document  structure. 

The  field  <num-str>  is  a  character  string  that  represents  the  identifier  of  the  table  being  laid  out.  It  is 
obtained  from  the  binding  'numberstring-<n>'  which  is  specified  for  the  logical  object  of  the  type  Table 
which  is  being  laid  out.  That  is,  the  field  <num-str>  is  derived  from  the  current  instance  of  the 
constituent  constraint  of  the  type  Table. 

The  general  format  of  the  field  <num-str>  and  the  mechanisms  used  to  specify  and  generate  this  field 
are  described  in  6.6.7.3. 

Tables,  like  figures,  may  be  independently  numbered  throughout  a  document,  or  their  numbers  may  t)e 
linked  to  the  segments  in  which  they  are  contained.  An  example  of  a  table  number  is  the  string  '1.1.5' 
where  '1.1'  is  the  number  of  the  segment  to  which  the  table  belongs,  '.'  is  a  separator  and  '5'  is  the 
number  associated  with  the  particular  table. 


6.6.7.7  Footnote  numbering 

The  constituent  constraints  FootnoteReference  and  FootnoteNumber  contain  content  generators  which, 
when  evaluated  during  the  layout  process,  produce  character  strings  that  serve  to  identify  the  Footnote 
to  which  the  constituent  constraints  FootnoteReference  and  FootnoteNumber  are  subordinate. 

The  format  of  this  character  string  is  as  follows: 

<pre-str><num-str><suf-str> 

This  string  is  defined  by  a  string  expression  specified  by  the  macro  FNNUMBER  (see  7.3.1). 
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The  numbering  mechanism  is  the  same  as  that  used  for  numbering  segments  (see  6.6.7.3).  Thus  the 
fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  character  strings  respectively  which  may  be 
of  any  length.  These  are  derived  from  bindings  of  the  type  'prefix-<n>'  and  'suffix-<n>'  respectively  that 
are  defined  on  constituents  at  a  higher  level  in  the  document  stmcture. 

The  field  <num-str>  may  be  derived  by  one  of  three  methods.  It  may  be  represented  by  bindings  of  the 
type  *numberstring-<n>'  which  are  derived  using  an  expression  specified  by  the  macro 
USENUf^BERSTRINGS  as  described  in  6.6.7.3.  Alternatively,  it  may  be  derived  from  a  binding  of  the 
type  'fnotestring'  which  is  specified  on  the  constituent  Footnote  to  which  the  constituent  constraints 
FootnoteReference  and  FootnoteNumber  are  subordinate.  This  field  is  automatically  generated  using 
expressions  defined  by  the  macros  INCFNOTENUMBER  and  FNOTENUMBERSTRING.  The  field 
<num-str>  may  also  be  explicitly  specified;  this  case  is  defined  by  the  macro  FNOTESTRINGLITERAL. 

The  above  mechanisms  allow  footnotes  to  be  numbered  consecutively  throughout  a  document,  or  any 
number  of  independent  footnote  numbering  schemes  may  be  used.  For  example,  the  footnotes 
applicable  to  segments,  figures  and  tables  may  all  be  independently  numbered. 

6.6.7.8  Page  numbering 

The  constituent  constraint  PageNumber  is  specifically  provided  to  represent  common  content  that 
contains  a  page  number  and  that  is  to  be  placed  on  each  successive  page  of  a  document.  A 
mechanism  is  provided  which  allows  the  page  number  to  be  automatically  incremented  on  each 
successive  page  of  a  document. 

The  format  of  the  content  generator  specified  by  the  constituent  PageNumber  is  as  follows: 

<pre-str><num-str><pre-str> 

This  format  is  defined  by  a  string  expression  specified  by  the  macro  PGNUfvlBER  (see  7.3.1). 

The  fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  character  strings  respectively  which  may 
be  of  any  length.  These  may  be  explicitly  specified  in  the  expression,  or  they  may  be  derived  from 
bindings  of  the  type  'prefix-<n>'  and  'suffix-<n>'  respectively  that  are  defined  on  constituents  at  a  higher 
level  in  the  document  structure. 

The  field  <num-str>  is  the  page  number.  This  consists  of  a  single  number  derived  from  the  binding 
'number-<n>'  or  'PGnum'  which  is  specified  for  the  current  instance  of  the  frame  or  page  in  which  the 
page  number  is  to  be  laid  out.  A  page  number  may  be  represented  in  the  form  of  Arabic  numeric 
strings,  an  upper  or  lower  case  Roman  numeric  string  or  an  equivalent  upper  or  lower  case  alphabetic 
string.  (1 


The  binding  ■number-<n>'  is  initialized  at  the  document  layout  root,  page  set  level  or  a  particular  page 
class  (using  the  macro  INITIALISEBINDINGS  defined  in  7.3.1)  The  binding  PGnum'  is  initialized  at 
the  document  layout  root  or  page  set  level  (using  the  macro  INITIALISEPGNUM  defined  in  7.3.1).  This 
binding  is  automatically  incremented  on  each  successive  page  using  an  expression  specified  by  the 
macro  USEPGNUt^BERS  (see  7.3.1).  By  placing  initialization  on  the  layout  root,  rather  than  on  the 
pageset  classes,  the  pagenumbering  may  be  defined  to  be  continued  from  one  pageset  to  the  next. 

The  content  associated  with  logical  object  classes  of  the  type  PageNumber  is  laid  out  in  a  frame  of  one 
of  the  following  types:  BasicHeader,  BasicFooter.  SourcedContentVariable,  SourcedContentFixed  (see 
6.3.6)  using  the  logical  source  mechanism.  Thus  when  the  appropriate  frame  is  being  laid  out,  the  field 
<num-expr>  in  the  content  generator  contained  in  a  logical  object  class  of  the  type  PageNumber  is 
evaluated,  and  this  determines  the  value  of  the  binding  'number-<n>'  or  PGnum  that  is  associated  with 
the  current  page  being  laid  out. 
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Similar  numbering  is  applicable  for  page  sets. 
-  6.6.7.9  Referenced  content 

ReferencedContent  is  a  constituent  constraint  that  is  provided  to  support  a  general  referencing 
mechanism  within  the  content  of  the  body  part  of  a  document.  This  constituent  constraint,  therefore,  is 
used  to  represent  character  content  that  contains  a  reference  to  content  specified  elsewhere  in  a 
document.  Examples  are  references  to  strings  that  represent  the  numbers  of  segments,  figures,  tables, 
'footnotes  and  pages.  Particular  strings  specified  by  'string-<n>'  may  be  referenced. 

This  constituent  constraint  contains  a  content  generator  which,  when  evaluated,  produces  a  character 
string  of  the  following  form; 

;  <pre-str>  a  sequence  of  <ref-str><suf-str> 

This  content  generator  is  defined  by  a  string  expression  which  is  specified  by  the  macro  REF  (see 
7.3.1).  • 

j  The  fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  character  strings  which  may  be  explicitly 
'  defined  in  the  expression  or  may  be  derived  from  bindings  of  the  type  'prefix-<n>'  and  'suffix-<n>' 
respectively  that  are  defined  on  constituents  at  a  higher  level  in  the  document  structure. 

The  field  <ref-str>  is  a  character  string  that  is  obtained  from  content  specified  on  a  particular  constituent 
In  the  document  by  reference  to  one  of  the  following  bindings:  'numberstring-<n>',  'number-<n>',  'string- 
<n>',  fnotestring'  or  PGnum'. 

The  following  referencing  mechanisms  are  permitted  in  this  case; 

—  a  particular  logical  object  is  referenced  for  the  required  binding; 

—  a  particular  logical  object  is  referenced  and  a  search  for  the  required  binding  is  made 
on  the  logical  objects  superior  to  the  referenced  object. 

The  referencing  mechanism  shall  take  into  account  the  constituents  for  which  the  particular  bindings  are 
permitted,  as  defined  in  6.6.7.2. 


6.6.7.10  Common  references 

CommonReference  is  a  constituent  constraint  with  in  the  common  part  of  the  logical  stmcture  of  a 
document  that  represents  common  character  content  that  may  be  reproduced  in  more  than  one  place  in 
a  document.  This  constituent  constraint  is  specifically  provided  to  represent  content  which  contains  a 
reference  to  content  specified  elsewhere  in  a  document.  This  content  is  specified  by  bindings. 
Examples  are  references  to  character  strings  that  represent  the  numbers  of  segments,  figures,  tables 
and  footnotes  in  a  document. 

This  constituent  constraint  contains  a  content  generator,  the  general  format  of  which  Is  the  same  as  the 
content  generator  specified  for  the  constituent  constraint  ReferencedContent  (see  6.6.7.9)  and  content 
may  be  obtained  from  the  following  bindings;  'numberstring-<n>',  'numbers-<n>',  'string-<n>', 
'fnotestring'  or  'PGnum'. 

This  content  generator  is  defined  by  an  expression  which  is  specified  by  the  macro  COMMONREF. 
The  following  referencing  mechanisms  are  permitted  in  this  case; 
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—  a  current  page  or  frame,  or  a  logical  object  which  is  laid  out  currently  is  referenced  for 
the  required  binding; 

—  a  current  page  or  frame,  or  a  logical  object  which  is  laid  out  currently  is  referenced  and 
a  search  for  the  required  binding  is  made  on  the  constituents  superior  to  a  referenced 
constituent; 

—  a  page  or  frame  into  which  a  particular  logical  object  is  laid  out  is  referenced  for  the 
required  binding; 

—  a  page  or  frame  into  which  a  particular  logical  object  is  laid  out  is  referenced  and  a 
search  for  the  required  binding  is  made  on  the  layout  objects  superior  to  the  referenced 
page  or  frame. 

The  referencing  mechanism  shall  take  into  account  the  constituents  for  which  the  particular  bindings  are 
permitted,  as  defined  in  6.6.7.2. 

6.6.7.1 1  Current  instance  references  f 

The  constituent  constraint  Currentlnstance,  like  Comnx)nReference,  represents  common  character  i 
content  that  may  be  reproduced  in  more  than  one  place  in  a  document  when  it  is  laid  out.  li 

This  constituent  constraint  is  specifically  provided  to  represent  the  current  instance  of  a  character  string  ' 

that  is  to  be  laid  out  in  multiple  places  in  a  document.  A  typical  example  is  the  reproduction  of  a  title  of  j 
chapter  on  each  page  of  a  document  in  which  that  chapter  is  reproduced. 

The  constituent  constraint  Currentlnstance  contains  a  content  generator,  the  general  format  of  which  is  | 
the  same  as  the  content  generator  specified  for  the  constituent  constraint  ReferencedContent.  This 
content  generator  is  restricted  to  referencing  content  obtained  from  bindings  of  the  type  'string-<n>'. 

■i 

The  referencing  mechanism  allows  bindings  of  the  type  ■string-<n>'  to  be  referenced  for  the  current  | 

instance  of  a  logical  constituent  of  a  specified  class  or  the  current  instance  of  a  particular  frame  or  ] 

page.  i 

i 

The  format  of  this  content  generator  is  defined  by  the  macro  CURRENTINSTANCE  (see  7.3.1). 


6.6.7.12  Common  number  references 

The  constituent  constraint  CommonNumt>er  represents  common  character  content  that  may  be 
reproduced  in  more  than  one  place  in  a  document  when  it  is  laid  out. 

This  constituent  constraint  is  specifically  provided  to  represent  identifiers  of  other  parts  of  a  document, 
that  is,  character  strings  that  represent  the  numbers  of  segments,  figures  and  tables  within  a  document. 

This  constituent  constraint  contains  a  content  generator,  the  general  format  of  which  is  the  same  as  the 
content  generator  specified  for  the  constituent  constraint  ReferencedContent  (see  6.6.7.9).  This  content 
generator  may  reference  content  specified  by  the  bindings  'numberstring-<n>'  and  'numbers-<n>'. 

The  format  of  this  content  generator  is  defined  by  the  macro  COMMONNUMBER  (see  7.3.1). 

li 
\ 
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j  6.6.8  User  readable  comments 

Information  which  is  to  be  interpreted  as  comments  relevant  to  constituents  and  associated  content 
1  portions  may  be  specified  using  the  attribute  "user  readable  comments".  This  information  is  intended 
for  presentation  to  humans. 

The  information  consists  of  a  string  of  characters  which  shall  belong  to  one  of  the  graphic  character 
sets  indicated  in  the  document  profile  attribute  "comments  character  sets"  (see  6.7.4.2).  If  the  latter 
attribute  is  not  explicitly  specified,  then  the  default  defined  in  [CCITT  Recommendation  T.410  series  | 
ISO  8613]  is  assumed.  The  control  functions  space  (SP),  carriage  return  (CR)  and  line  feed  (LF)  and 
code  extension  control  functions  may  also  be  used  within  the  character  string,  but  no  other  control 
functions  are  allowed. 


6.6.9  User  visible  name 

Information  which  may  be  used  to  identify  constituents  within  a  document  may  be  specified  using  the 
attribute  "user  visible  name".  This  information  is  intended  for  presentation  to  humans,  for  example,  to 
assist  in  the  editing  of  documents. 

The  information  consists  of  a  string  of  characters  which  shall  belong  to  one  of  the  graphic  character 
sets  indicated  in  the  document  profile  attribute  "comments  character  sets"  (see  6.7.4.2).  If  the  latter 
attribute  is  not  explicitly  specified,  then  the  default  defined  in  (CCITT  Recommendation  T.410  series  | 
ISO  8613]  is  assumed.  The  control  functions  space  (SP),  carriage  return  (CR),  line  feed  (LF)  and  code 
extension  control  functions  may  also  be  used  within  the  character  string,  but  no  other  control  functions 
are  allowed. 


6.7  Document  management  features 

Information  relating  to  the  document  as  a  whole  is  specified  in  the  document  profile  which  is 
represented  by  the  constituent  DocumentProfile.  This  constituent  shall  be  specified  in  every  document. 

The  information  in  the  document  profile  is  classified  into  the  following  categories: 

a)  document  constituent  information; 

b)  document  identification  information; 

c)  document  default  information; 

d)  non-basic  characteristics  information; 

e)  document  management  information. 

The  information  in  the  document  profile  may  be  of  interest  to  the  user,  or  may  be  used  for  machine 
processing  of  the  document. 


6.7.1  Document  constituent  information 

This  information  specifies  which  constituents  are  used  to  represent  the  document,  including  constituents 
that  are  external  to  the  interchanged  document.  This  information  is  divided  into  three  categories. 
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6.7.1.1  Presence  of  document  constituents 

This  information  indicates  which  constituents  are  included  in  the  document.  That  is.  this  information 
indicates  whether  or  not  the  document  contains  a  generic  logical  stmcture,  a  specific  logical  stnjcture,  a 
generic  layout  stmcture,  a  specific  layout  structure,  layout  styles  and  presentation  styles  (see  note).  It 
is  mandatory  to  specify  this  information  in  the  document  profile. 

NOTE  27  -  If  the  generic  logical  or  layout  structure  is  external  to  the  document  (see  6.7.1.3),  then  it  is  still 
necessary  to  indicate  that  these  structures  are  present  and  form  part  of  the  document. 


6.7.1.2  Resource  document  information 

This  information  consists  of  a  reference  to  a  generic-document  referred  to  as  a  resource  document  (see 
6.6.1).  This  is  specified  by  the  attribute  "resource  document".  If  constituents  in  the  document  contain 
references  to  object  classes  in  a  resource  document,  then  it  is  mandatory  to  specify  this  information  in 
the  document  profile. 


6.7.1.3  External  document  information 

This  information  consists  of  a  reference  to  an  external  document  which  may  consist  of  a  generic  logical 
stmcture  or  both  the  generic  logical  and  the  generic  layout  stmctures  (see  6.6.2).  If  such  a  reference  is 
required,  then  it  is  specified  by  the  attribute  "external  document  class"  in  the  document  profile. 


6.7.2  Document  identification  information 

This  information  relates  to  the  identification  of  the  document.  This  information  is  divided  into  six 
categories. 


6.7.2.1  Document  application  profile  information 

This  information  indicates  the  document  application  profile  to  which  the  document  belongs.  It  is 
mandatory  to  specify  this  information  using  the  attribute  "document  application  profile". 

6.7.2.2  Document  architecture  class  information 

This  information  indicates  the  document  architecture  class  to  which  the  document  t>elongs  (see  6.1).  It 
is  mandatory  to  specify  this  information  using  the  attribute  "document  architecture  class". 


6.7.2.3  Content  architecture  classes  Information 

This  information  indicates  the  content  architecture  classes  used  in  the  document  (see  6.5.1.2,  6.5.2.2 
and  6.5.3).  It  is  mandatory  to  specify  this  information  using  the  attribute  "content  architecture  classes". 

6.7.2.4  Interchange  format  class  information 

This  information  indicates  the  interchange  format  class  used  to  represent  the  document  (see  clause  8). 
It  is  mandatory  to  specify  this  information  using  the  attribute  "interchange  format  class". 
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6.7.2.5  OOA  version  information 

This  information  indicates  the  [CCITT  Recommendation  |  ISO  standard]  to  which  the  document 
conforms.  It  also  specifies  a  calendar  date,  which  indicates  that  the  document  conforms  to  the  version 
of  the  [CCITT  Recommendation  |  ISO  standard]  and  any  addenda  that  are  current  on  that  date.  It  Is 
mandatory  to  specify  this  information. using  the  attribute  "ODA  version". 

6.7.2.6  Document  reference 

This  information  serves  to  identify  the  document.  Typically  this  information  is  allocated  to  the  document 
by  the  creator  of  the  document.  The  identifier  may  consist  of  an  ASN.1  object  identifier  or  a  string  of 
characters.  It  is  mandatory  to  specify  this  information  using  the  attribute  "document  reference". 

6.7.3  Document  default  information 

This  information  specifies  various  default  values  for  attributes  used  in  the  document.  The  default 
values  that  are  allowed  are  specified  in  the  various  subclauses  of  clause  6.  The  specification  of  this 
information  is  only  required  when  it  is  required  to  specify  a  default  value  which  is  other  than  the 
standard  default  value  specified  in  [CCITT  Recommendation  T.410  series  |  ISO  8613]. 

Default  values  for  the  following  groups  of  attributes  may  be  specified: 

—  document  architecture  attributes; 

—  character  content  attributes; 

—  raster  graphics  attributes; 

—  geometric  graphics  attributes. 

6.7.4  Non-basic  characteristics  information 

This  information  specifies  the  non-basic  attribute  values  specified  in  the  document.  It  is  mandatory  to 
specify  a  non-basic  attribute  values  in  the  document  profile  when  such  a  value  is  used  in  the  document. 

The  following  types  of  non-basic  attribute  values  may  be  specified: 

—  profile  character  sets; 

—  comments  character  sets; 

—  alternative  representation  character  sets; 

—  page  dimensions; 

—  medium  type; 

—  character  presentation  features; 

—  raster  graphics  presentation  features; 

—  raster  graphics  coding  attributes. 
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NOTE  28  -  In  addition  to  the  above,  layout  paths  and  borders  may  be  specified  for  upwards  compatibility  with 
FOD26. 

Further  information  concerning  document  profile,  comments  and  alternative  representation  character 
sets  is  given  below. 


6.7.4.1  Profile  character  sets 

Some  document  profile  attribute  have  values  consisting  of  character  strings,  for  example,  the  document 
management  attributes.  The  character  sets  used  in  these  character  strings  are  specilied  by  the 
document  profile  attribute  "profile  character  sets". 

This  attribute  "profile  character  sets"  specifies  a  code  extension  announcer  and  designations  of 
character  sets,  which  are  subject  to  the  following  restrictions: 

a)  the  code  extension  announcer  shall  be  04/03  when  specified.  This  code  extension 
announcer  means  to  use  GO  and  G1  sets  in  an  8-bit  environment  and  also  the 
invocation  of  GO  and  G1  sets  into  GL  and  GR  respectively.  Thus,  in  each  attribute  to 
which  this  attribute  applies,  invocation  shift  functions  are  not  necessary  because  GO 
and  G1  sets  are  implicitly  invoked  by  this  code  extension  announcer. 

b)  GO  set:  only  IS0-IR6  (the  IRV  of  ISO  646  revised  1991),  IS0-IR2  (the  primary  set  of 
ISO  6937-2),  or  any  other  version  of  ISO  646  may  be  designated  for  this  set;  these 
graphic  character  sets  are  implicitly  invoked  in  GL. 

c)  G1  set:  no  restrictions  are  placed  on  the  graphic  character  sets  that  may  be  designated 
for  this  set.  These  graphic  character  sets  are  implicitly  invoked  in  GR. 

d)  the  empty  set  shall  be  designated  into  Gl  and  invoked  into  GR  if  no  other  specific 
character  set  is  invoked  in  GR. 

If  the  attribute  "profile  character  sets"  is  not  specified,  then  the  default  defined  in  [CCITT 
Recommendation  T  410  series  |  ISO  8613]  is  assumed. 


6.7.4.2  Comments  character  sets 

The  character  sets  assumed  to  have  been  designated  and  optionally  invoked  at  the  beginning  of  the 
character  strings  specified  by  the  atthbutes  "user  readable  comments"  (see  6.6  8)  and  "user  visible 
name"  (see  6.6.9)  are  specified  using  the  document  profile  attribute  "comments  character  sets". 

it  also  specifies  code  extension  techniques  and  the  graphic  character  sets  which  may  be  used  in  the 
attributes  "user  readable  comments"  and  "user  visible  name". 

If  this  attribute  is  specified,  the  code  extension  techniques  which  may  be  used  in  the  attributes  "user 
readable  comments"  and  "user  visible  name"  shall  be  announced  by  appropriate  code  extension 
announcers.  The  use  of  GO  set  and  GL  shall  always  be  announced.  Other  code  extension  announcers 
are  to  be  specified  according  to  the  requirements  of  a  particular  document. 

Two  kinds  of  code  extension  techniques  are  permitted  for  this  attribute.  One  is  to  GL  and  GR  without 
shift  functions,  and  the  other  is  to  use  various  character  sets  by  shift  functions  The  former  is  rather 
restricted,  but  no  shift  functions  are  necessary  in  the  "user  readable  comments"  and  user  visible 
name". 
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The  same  restrictions  as  in  6.7.4.1  is  applied  in  this  case.  The  latter  permits  various  usages  of 
character  sets,  but  invocations  shall  be  specified  by  shift  functions  in  the  "user  readable  comment"  and 
"user  visible  name".  The  same  restriction  as  in  6.5.4  is  applied  in  this  case. 

All  the  graphic  character  sets  which  may  be  used  in  the  attribute  "user  readable  comments"  and  "user 
visible  name"  should  be  designated  in  the  "comments  character  sets". 

There  are  no  restrictions  concerning  the  number  of  graphic  character  sets  which  are  designated  and/or 
Invoked  in  the  "comments  character  sets";  hence  designation  to  the  same  G  set  overrides  the  previous 
G  set. 

If  the  attribute  "comments  character  sets"  is  not  specified,  the  default  defined  in  [CCITT 
Recommendation  T.410  series  |  ISO  8613]  is  assumed. 


6.7.4.3  Alternative  representation  character  sets 

This  attribute  specifies  the  graphic  character  sets  designated  and  invoked  at  the  beginning  of  the 
attribute  "alternative  representation"  other  than  the  standard  default  graphic  character  sets. 

The  restriction  on  profile  character  sets  described  in  6.7.4.1  is  also  applied.  If  this  attribute  is  not 
explicitly  specified  in  the  document  profile,  the  default  defined  in  [CCITT  Recommendation  T.410  sehes 
I  ISO  8613]  is  assumed. 


6.7.5  Fonts  list 

This  information  specifies  all  the  fonts  (if  any)  used  in  the  document.  It  is  specified  using  the  attribute 
"Fonts  list"  (see  Annex  B.2). 

6.7.6  Document  management  attributes 

Document  management  attributes  contain  information  about  the  content  of  the  document  and  its 
purpose.  Information  relating  to  the  following  may  be  specified: 

—  document  description  (see  note); 

—  dates  and  times; 

—  originators; 

—  other  user  information; 

—  external  references; 

—  local  file  references; 

—  content  attributes; 

—  security  information. 

The  attributes  that  may  be  used  to  specify  this  information  are  defined  in  [CCITT  Recommendation 
T.414  I  ISO  8613-4]. 
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The  string  of  characters  used  in  the  document  management  attributes  shall  t>elong  to  the  character  set 
indicated  in  the  document  profile  attribute  "profile  character  sets"  (see  6.7.4.1).  If  the  latter  attribute  is 
not  explicitly  specified  in  the  docunnent  profile,  then  the  default  character  set  is  the  minimum 
subrepertoire  of  ISO  6937-2. 

The  control  functions  space  j(SP).  carriage  return  (CR)  and  line  feed  (LF)  may  also  be  used  within  the 
character  strings,  t>u\  no  other  control  functions  are  allowed.  Therefore,  the  graphic  character  set 
cannot  be  changed  in  the  document  management  attributes. 

NOTE  29  -  The  document  description  includes  the  specification  of  the  document  reference  (see  6.7.2.6). 
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7  Specification  of  constituent  constraints 


7.1  Introduction 

The  structure  diagrams  illustrating  the  relationships  between  the  constituents  in  the  logical  structures 
are  shown  in  7.1.1.  The  macros  indicated  on  these  diagrams  are  defined  in  7.3.1.  These  macros 
define  the  permissible  values  for  the  attribute  "generator  for  sutiordinates"  that  are  applicable  to  the 
constituents,  and  define  the  allowed  structures  that  are  supported  by  this  profile. 

The  structure  diagrams  illustrating  the  layout  structures  are  shown  in  7.1.2.  The  macros  indicated  on 
these  diagrams  are  defined  in  7.4.1. 


7.1.1  Diagrams  of  relationships  of  logical  constituents 
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Figure  21  —  DocumentLogicalRoot,  1st  level 
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Figure  22  —  DocumentLogicalRoot,  2ncl  level 
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Figure  23  —  Title,  Paragraph  and  ListTerm 
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Figure  24  —  Phrase,  Caption  and  Description 
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Figure  25  —  Footnote 
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Figure  26  —  Figure 
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Figure  27  —  Form 
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Figure  28  —  Table 


Figure  29  —  Reference 
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Figure  30  —  NumberedList 


10 


UnNumber edL  i  stGFS 


Body 
Text 


Body 
Raster 


Body 

Geometr  i  c 


L I  St  I tem 


Phrase 


L I  St  I temGFS 


Numbered 
List 


04 


UnNumbered 
L  ist 


Def  i  n  i  t  i  on 
L  i  St 


09 


10 


11 


Figure  31  —  UnNumberedList 
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Figure  32  —  DefinltionList 
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Figure  33  —  CommonContent 
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7.1.2  Diagrams  of  relationships  of  layout  constituents 
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Figure  35  —  Page,  RectoPage  and  VersoPage 
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Figure  36  —  CompositeHeader,  CompositeFooter  and  CompositeCommon 


Basic 
Fixture 


Co  I umn 
F  i  xed 


Compos  i  te 
F  i  xture 
F  i  xed 


09 


03 


F 1  xedConnpos  I  teBodyGFS 


Var  i  ab  i  e 
Compos  i  te 
Body 


Connpos  I  te 
Common 


04 


Sourced 
Content 
F  I  xed 


02 


Arranged 
Content 
F  i  xed 


Gener  i  c 
Block 


Figure  37  —  FixedCompositeBody 


113 


Snat£  I  ng 
Co  I umns 


OS 


Basic 
F  loat 


Synchronized 
Co  I umns 


0-^ 


Var  iableComposi  teBodyGFS 


Compos  I te 
Float 


07 


Footnote 
Area 


Table 
Area 


11 


Compos  i  te 
F I xture 
Var I ab I e 


09 

Arranged 
Content 
Var  i  ab 1 e 

Sourced 
Content 
Var  j  ab 1 e 

Gener  i  c 
Block 


Figure  38  —  VariabieCompositeBody 
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Figure  39  —  SnakingCoiumns 
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Figure  41  —  CompositeFloat 
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Figure  42  —  CompositeColumnVariable  and  CompositeColumnFixed 
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7.1.3  Notation 


This  clause  is  written  in  accordance  with  the  Document  Application  Profile  and  Notation  (DAPPN)  of 
[CCITT  Recommendation  T.413  |  ISO  8613-1],  Annex  F.  The  following  clarifications  and  minor 
extensions  apply: 

a)  (Clarification]  The  value  range  definition  for  the  attributes  "subordinates"  and  "imaging- 
order"  specify  the  set  of  object  instances  that  may  occur.  The  ordering  and  number 
(which  may  be  zero)  of  object  instances  for  the  attribute  "subordinates"  shall  be  in 
accordance  with  the  value  of  the  attribute  "generator  for  sul^ordinates"  in  the  respective 
object  class. 

b)  (Clarification]  The  value  "ANY_STRING"  can  include  code  extension  control  functions  as 
well  as  graphic  characters. 

c)  (Extension]  In  order  to  write  the  specification  of  the  usage  of  character  sets  and  code 
extension  control  functions  precisely,  the  following  extensions  are  applied: 


1)  Following  symbols  are  introduced  to  denote  shift  functions: 


Symbol  Shift  function  Coded  representation 

LSO  Locking  shift  zero  00/15 

LS1R  Locking  shift  one  right  ESC  07/14 

LS2R  Locking  shift  two  right  ESC  07/13 

LS3R  Locking  shift  three  right  ESC  07/12 

552  Single  shift  two  08/14 

553  Single  shift  three  08/15 


2)  <escape-sequence>  is  extended  to  include  shift  functions: 

<escape-sequence>  ::=  ESC  <octet>...  (<invocation-control-function>]; 
<invocation-control-function>  ::=  'LSOTLSI RTLS2RTLS3RTSS2TSS3'; 

3)  Data  type  specification  for  #ESC  in  content  information  is  extended  as: 

<escape-sequence> . . . 

d)  (Clarification]  When  an  attribute  value  is  specified  by  a  set  of  production  rules,  a  non- 
terminating  symtx)l  which  occurs  first  is  its  start  symbol.  Note  that  start  symbols  other 
than  <object-id-expr>,  <string-expr>  and  <construction-expr>  are  used. 

e)  (Extension)  Data  type  specifications  other  than  those  specified  in  the  tables  in  DAPPN 
are  applied  for  some  attributes  within  the  range  that  the  base  standard  permits 

f)  [Extension]  "1"  is  used  in  CASE  SUPERIOR  expressions  in  the  following  format  in  order 

to  shorten  the  text: 

CASE  SUPERIOR  ({const1|const2|...|constn}(aaaa))  OF  (  } 

where  consti,  const2  constn  are  names  of  constituent  constraint,  aaaa  is  a  name  of 

attribute. 

This  expression  is  syntactically  equivalent  to  the  following  expression: 

CASE  SUPERIOR  (consti (aaaa))  OF  {  } 

CASE  SUPERIOR  (const2(aaaa))  OF  {  } 
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CASE  SUPERIOR  (constn(aaaa))  OF  {  } 


When  CASE  SUPERIOR  is  evaluated,  constituents  are  searched  from  the  Imnnediate  superior 
to  the  root.  Only  the  first  one  which  satisfies  one  of  the  constituent  constraints  constl.  const2, 
....  and  constn  is  selected  and  the  attribute  aaaa  in  it  is  tested. 


7.2  Document  profile  constituent  constraints 


7.2.1  Macro  definitions 

DEFINE(FC.  •'ASN.1{2  8  2  6  0}"  --  formatted  character  content  --) 
DEFINE(PC,  ■•ASN.1(2  8  2  6  1}"  --  processable  character  content  --) 
DEFINE(FPC,  "ASN.1{2  8  2  6  2}"  --  formatted  processable  character  content  -) 
DEFINE(FPR,  "ASN.1{2  8  2  7  2}"  -  formatted  processable  raster  graphics  content  --) 
DEFINE(FPG.  "ASN.1{2  8  2  8  0}"  -  formatted  processable  geometric  graphics  content  --) 


DEFINE(FDA,  "{formatted}") 

DEFINE(PDA.  "{processable}") 

DEFINE(FPDA.  "{'formatted-processable'}") 

DEFINE(PDA-FPDA,  "{'processableTformatted-processable'}") 

DEFINE(DAC.  "DocumentProfile  (Document-architecture-class)") 
DEFINE(GLAS,  "DocumentProfile  (Generic-layout-structure)") 
DEFINE(COf^PLETE,  "{  complete-generator-set  }") 


DEFINE(BasicPageDimensions. " 

REQ  #horizontal-dimension 

{REQ  #fixed-dimension{<=9240}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension{<=12400}} 
I  REQ  #hori2ontal-dimension 

{REQ  #fixed-dimension{<=12400}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension{<=9240}} ") 

Any  size  equal  to  or  smaller  than  CARA  (Common  Assured  Reproduction  Area)  of  ISO  A4  and 
ANSI-A.  Both  Portrait  and  Landscape  may  be  specified.  Note  that  the  atx)ve  macro  is  defined 
for  clarification  of  the  specification  and  is  not  used  in  any  other  part  of  this  DAP  specification.  - 


DEFINE(NonBasicPageDimensions,  " 

REQ  #hor!zontal-dimension 

{REQ  #fixed-dimension{<=39680}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {12401. .56120}} 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension{9241  .39680}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {<=56120}} 

-  up  to  ISO  AO  portrait  - 
|REQ  #horizontal-dimension 
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{REQ  #fixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 

-  up  to 
I  REQ  #hori2ontal-dimension 

{REQ  #1ixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 
I  REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 
--  up  to 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #vertical -dimension 

{REQ  #fixed-dimension 
|REQ  #horizontal-dimension 

{REQ  #ftxed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 
--  up  to 
|REQ  #horizontal-dimension 

{REQ  #tixed-dimension 
REQ  #vertical-dimension 

{REQ  #1ixed-dimension 
|REQ  #horizontal-dimension 

{REQ  #tixed-dimension 
REQ  #vertical-dimension 

{REQ  #tixed-dimension 
--  up  to 
|REQ  #horizontal-dimension 

{REQ  #lixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimenslon 
I  REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 

-  up  to 


{<=56120}}. 

{9241.39680}} 

{12401. .56120}}. 

{<=39680}} 

ISO  AO  landscape  - 

{<=40800}}. 

{12401.. 52800}} 

{9241.. 40800}}. 

{<=52800}} 
ANSI-E  portrait  -- 

{<=52800}}. 

{9241.40800}} 

{12401.. 52800}}. 

{<=40800}} 
ANSI-E  landscape  - 

{<=12141}}. 

{12401. .17196}} 

{9241. .12141}}. 

{<=17196}} 

J  IS  B4(  Japanese  legal)  portrait  ~ 

{<=17196}}, 

{9241. .12141}} 

{12401. .17196}}. 

{<=12141}} 

J  IS  B4(  Japanese  legal)  landscape 
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DEFINE(PermissiblePageDimensions. " 

REQ  #horizontal-dimension 

{REQ  #1ixed-dimension 
REQ  #ver1ical-dimension 

{REQ  #fixed-dimension 
I  REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #ver1ical -dimension 

{REQ  #fixed-dimension 
|REQ  #horizontal-dimension 

{REQ  #fixed-dimension 
REQ  #vertical-dimension 

{REQ  #fixed-dimension 

") 


{<=39680}}. 

{<=56120}}  --  up  to  ISO  AO  portrait  -- 
{<=56120}}. 

{<=39680}}  --  up  to  ISO  AO  landscape 
{<=40800}}. 

{<=52800}}  --  up  to  ANSI-E  portrait  -- 

{<=52800}}. 

{<=40800}}  --  up  to  ANSI-E  landscape 


DEFINE(NominalPageSizes,  " 


REQ 

#horizontal-dimension 

{7015}. 

REQ 

#horizontal-dimension 

{9920}. 

REQ 

#horizontal-dimension 

{9920}. 

REQ 

#horizontal-dimension 

{14030}. 

REQ 

#horizontal-dimension 

{14030}, 

REQ 

#horizontal-dimension 

{19840}. 

REQ 

#horizontal-dimension 

{19840}. 

REQ 

#horizontal-dimension 

{28060}. 

REQ 

#horizontal-dimension 

{28060}. 

REQ 

#horizontal-dimension 

{39680}. 

REQ 

#horizontal-dimension 

{39680}. 

REQ 

#horizontal-dimension 

{56120}. 

REQ 

#horizontal-dimension 

{10200}. 

REQ 

#horizontal-dimension 

{16800}, 

REQ 

#horizontal-dimension 

{10200}. 

REQ 

#tiorizontal-dimension 

{13200}. 

REQ 

#horizontal-dimension 

{13200}. 

REQ  #vertical-dimension  {9920} 

-  ISO  A5  portrait  - 

REQ  #vertical-dimension  {7015} 

-  ISO  A5  landscape- 

REQ  #venical-dimension  {14030} 

-  ISO  A4  portrait  - 

REQ  #vertical-dimension  {9920} 

-  ISO  A4  landscape - 

REQ  #vertical-dimension  {19840} 

-  ISO  A3  portrait  - 

REQ  #vertical-dimension  {14030} 

-  ISO  A3  landscape  ~ 

REQ  #vertical-dimension{28060} 

-  ISO  A2  portrait  - 

REQ  #vertical-dimension  {19840} 

-  ISO  A2  landscape  - 

REQ  #vertical-dimensbn  {39680} 

--  ISO  A1  portrait  - 

REQ  #venical-dimension  {28060} 

-  ISO  A1  landscape  - 

REQ  #vertical-dimension  {56120} 

-  ISO  AO  portrait  - 

REQ  #vertical-dimension  {39680} 

-  ISO  AO  landscape  - 

REQ  #vertical-dimension  {16800} 

-  ANSI  legal  portrait  -- 

REQ  #ver1ical-dimension  {10200} 

-  ANSI  legal  landscape  - 

REQ  #vertical-dimension  {13200} 

-  ANSI-A  portrait  - 

REQ  #venical-dimension  {10200} 

-  ANSI-A  landscape  - 

REQ  #vertical-dlmension  {20400} 

-  ANSI-B  portrait  - 
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nbU 

#horizontal 

dimension 

HtU  #veriical-dimension  {13200} 
--  ANSI-B  landscape  -- 

ntU 

ff  nonzoniai 

•uimension 

ntu  fFvemcai-oimension  {i:D4uu| 
--  ANSI-C  portrait  -- 

ntU 

#horizonta! 

■oimension 

ntu  ffvemcai-dimension  (<:U4uu) 
--  ANSI-C  landscape  -- 

ntU 

#horizontal 

-dimension 

HtU  ffvertical-dimension  {40800} 
--  ANSI-D  portrait  -- 

RcU 

#horizontal 

■dimension 

1  A(\QC\t\\ 

{4UoUU), 

HtU  fFvenicai-dimension  {26400} 
--  ANSI-D  landscape  - 

RcQ 

#horizontal 

■dimension 

t  Ar\Qr\r\\ 
(4UoUU), 

HtU  ffvenicai-dimension  {o<ioOO} 
-  ANSI-E  portrait  - 

ntU 

#horizontal 

■dimension 

{o<;oUU), 

HtU  ffvenicai-aimension  {4Uouu) 
-  ANSI-E  landscape  - 

RcQ 

#horizontal 

-dimension 

{  J»3dOO), 

HtU  ffverticai-dimension  {4oOOO} 
-  ANSI-F  portrait  -- 

RtU 

#horizontal 

■dimension 

{4o00U), 

HtU  fFverticai-dimension  {JobOO} 
-  ANSi-F  landscape  - 

HtU 

#horizontal 

-dimension 

(1*:  141  J, 

HtU  ffvenicai-oimension  {i  /lyoj 
-  JIS  B4  (Japanese  legal)  portrait  - 

#horizontal 

-dimension 

{1  /  lyo), 

HtU  ffvenicai-uimension  {i<£i4i) 

-  JIS  B4  (Japanese  legal)  landscape  - 

RbU 

#horizontal 

-dimension 

HtU  ffvenicai-oimension  { i^:i4ij 
-  JIS  85  (Japanese  letter)  portrait  - 

ffnonzoniai 

-Dimension 

(1^:14  1), 

HtU  ffvenicai-uimension  {ooyoj 

--  JIS  85  (Japanese  letter)  landscape- 

DEFINE(GRAPHICRENDITIONS.  " 

{'cancelTincreased-intensity'  I'decreased-intensity' 
I'italicised'l  underlined'  I'slowly-blinking' 
I'rapidly-blinking  I  negative-image'l  crossed-out' 
iprimary-fontTfirst-alternative-tont' 
I  second -alternative-font'  |'third-alternative-font' 
I'fourth-alternatlve-font'  rtifth-alternative-font' 
I'sixth-alternative-font  Tseventh-alternative-font 
l  eighth-alternative-font'  I'ninth-alternative-font' 
I'doubly-undertined'  |  normal-intensity'  I'not-italicised' 
I'not-underlinedTsteady 'I'positive-image' 
I'not-crossed-out' } ...  ") 


Macro  defining  permissible  code  extension  announcers.  Note  that  all  the  values  are  basic 


DEFINE(CDEXTEN. 


"ESC  02/00  05/00. 
(ESC  02/00  05/03]  . 
[ESC  02/00  05/05]  , 
[ESC  02/00  05/07]  . 
[ESC  02/00  05/10]  , 
[ESC  02/00  05/11] 


-  Use  GO  &  LSO  - 

-  Use  01  &  LS1R  - 

-  Use  G2  &  LS2R  - 

-  Use  G3  &  LS3R  - 

-  Use  G2  &  SS2  - 
"  Use  G3  &  SS3  - 


--  Macro  defining  code  extension  announcers  for  DAP  defaults  -- 
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I 


DEFINE(DAP-DEFAULT-CDEXTEN.  "$CDEXTEN") 


Macros  defining  final  cfiaracter  for  designation  - 

DEFINE(FCORE.  "04/02      --  A  final  character  designating  ISO-IR  6  (the  IRV  of  ISO  646  revised 

1991.  i.e  ASCII) --") 

DEFINE(F646,   "        -  A  final  character  designating  any  version  of  ISO  646  except  ISO-IR  6  -") 

0EFINE(F94S.   "       -  A  final  character  designating  any  registered  94  single  byte  graphic  character 
set,  optionally  preceded  by  one  or  wore  internDediate  characters  as  define  in 
Annex  C  of  ISO  2022  -") 

DEFINE(F94M,   "       -A  final  character  designating  any  registered  94  nrKiIti  byte  graphic  character 
set,  optionally  preceded  by  one  or  more  intermediate  characters  as  define  in 
Annex  C  of  ISO  2022 

DEFINE(F96S,   "       -  A  final  character  designating  any  registered  96  single  byte  graphic  character 
set,  optionally  preceded  by  one  or  more  intermediate  characters  as  define  in 
Annex  C  of  ISO  2022  --") 

DEFINE(F96M.   "       -  A  final  character  designating  any  registered  96  multi  byte  graphic  character 
set,  optionally  preceded  by  one  or  more  intermediate  characters  as  define  in 
Annex  C  of  ISO  2022  --") 

DEFINE(FEMPTY.  "07/14  --  The  empty  set  -") 


-  Macro  defining  a  revision  number  of  a  character  set  - 

DEFINE(REV,  An  octet  between  04/00  and  07/14,  which  represents  a  revision  number  as  defined 
in  ISO  2022.  --") 


--  Macros  defining  designation  sequences  - 

DEFINE{DEG-CORE-G0.         "ESC  02/08  $FCORE") 

--  Designate  94  characters  of  ISO-IR  6  (the  IRV  of  ISO  646  revised  1991)  to  GO  -- 

DEFINE(DEG-646-G0,  "ESC  02/08  $F646") 

"  Designate  any  version  of  ISO  646,  except  ISO-IR  6,  to  GO  - 

DEFINE(DEG-ANY-G1.  "{[ESC  02/06  $REV] 

{  ESC  02/09  $F94S 
I  ESC  02/04  02/09  $F94M 
|ESC  02/13  $F96S 
|ESC  02/04  02/13  $F96M}}") 
~  Designate  any  character  set  to  G1  - 

DEFINE(DEG-ANY-G2,  "{(ESC  02/06  $REV] 

{  ESC  02/10  $F94S 
I  ESC  02/04  02/10  $F94M 
I  ESC  02/14  $F96S 
I  ESC  02/04  02/14  $F96M}}") 
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--  Designate  any  character  set  to  G2  -- 

DEFINE(DEG-ANY-G3.  "{(ESC  02/06  SREV] 

{  ESC  02/1 1  $F94S 
I  ESC  02/04  02/11  $F94M 
I  ESC  02/15  $F96S 
!  ESC  02/04  02/15  $F96M}}") 
-  Designate  any  character  set  to  G3  - 

DEFINE(DEG-EMPTY-G1.        "ESC  02/09  $FEMPTY") 
Designate  the  empty  set  to  G1  -- 


Macro  defining  permissible  graphic  character  sets.  -- 

DEFINE(PERMIT-GRCHAR,  "{SDEG-CORE-GO  LSO  |$DEG-646-G0  LSO}. 
{{$DEG-ANY-G1  LS1R 
|$DEG-ANY-G2  LS2R 
|$DEG-ANY-G3  LS3R}... 
|$DEG-EMPTY-G1  LS1R}") 


--  Macro  defining  graphic  character  sets  for  DAP  defaults  - 
DEFINE(DAP-DEFAULT-GRCHAR.  "$PERMIT-GRCHAR") 


Macro  defining  basic  graphic  character  sets.  Note  that  this  macro  is  defined  for  clarification  of 
the  specification  and  is  not  used  in  any  other  part  of  this  DAP  specification. 

DEFINE(BASIC-GRCHAR.       "$DEG-CORE-G0  LSO, 

$DEG-EMPTY-G1  LS1R") 


--  Macro  defining  non-basic  graphic  character  sets  -- 

DEFINE(NON-BASIC-GRCHAR.  "{$DEG-646-G0 

|$DEG-ANY-G1 
|$DEG-ANY-G2 
|$DEG-ANY-G3}...") 


--  Macro  defining  character  sets  used  In  document  profile  attributes  - 
DEFINE(PROFCHAR,  " 

ESC  02/00  04/03  --  announcement  to  use  GO  and  G1 .  and  to  invoke  into 

GL  and  GR  respectively,  (no  shift  functions  are 
necessary)-- 

{$DEG-CORE-G0  |  $DEG-646-G0  }  --  designate  GO  -- 
{$DEG-ANY-G1  |  $DEG-EMPTY-G1  }     aesignate  G1  -- 
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without  shift  functions  -- 
--  announcement  to  use  GO  and  G1 ,  and  to  invoke  into 
GL  and  GR  respectively,  (no  shift  functions  are 
necessary)-- 

{  $DEG-CORE-G0  |  $DEG-646-G0  }  designate  GO  -- 
{  $DEG-ANY-G1  |  $DEG-EMPTY-G1  }  --  designate  G1  -- 

I    --  in  the  case  to  use  various  character  sets  (shift  functions  are  necessary)  -- 

{ESC  02/00  05/00,  --  announcement  to  use  GO  and  LSO  -- 

(ESC  02/00  05/03],  -  announcement  to  use  G1  and  LS1R  - 
(ESC  02/00  05/05],                       -  --  announcement  to  use  G2  and  LS2R  -- 

(ESC  02/00  05/07],  --  announcement  to  use  G3  and  LS3R  -- 

[ESC  02/00  05/10],  -- announcement  to  use  G2  and  SS2  -- 

[ESC  02/00  05/1 1] }  --  announcement  to  use  G3  and  SS3  -- 


Macro  defining  comments  character  sets  -- 

€FINE(COMCHAR.  " 

in  the  case  to  use  twth  GL  and  GR 
ESC  02/00  04/03 


) 


{  $DEG-CORE-G0  |  $DEG-646-G0  }     --  designate  GO  -- 


{{$DEG-ANY-G1 
|$DEG-ANY-G2 
|$DEG-ANY-G3}... 
|$DEG-EMPTY-G1} 


--  designate  G1 
--  designate  G2 
--  designate  G3 


-  Macro  defining  character  sets  used  for  alternative  representation 
DEFINE(ALTCHAR,  "$PROFCHAR") 

7.2.2  Constituent  constraints 


7.2.2.1  DocumentProfile 


{ 

CASE  $DAC  OF 


$FDA:  PERM  Generic-layout-structure  {'factor-set'}, 
PERM  Specific-layout-structure  {'present'}, 
~  must  be  present  in  the  case  of  complete  document  and  not  present 

in  the  case  of  generic  document 
PERM  Presentation-styles  {'present'} 


$PDA:  PERM  Generic-layout-structure  {'complete-generator-set'}, 
PERM  Generic-logical-structure  {'complete-generator-sef 

I'partial-generator-set'} , 
--  must  be  present  if  there  is  no  external  document  class  reference  -- 
PERM  Specific-logical-structure  {'present'}, 
~  must  be  present  in  case  of  complete  document  and  not  present 

in  the  case  of  generic  document 
PERM  Presentation-styles  {'present'}, 
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PERM  Layout-styles 


{■present} 


$FPDA:  PERM  Generic-layout-structure  {'complete-generator-set'}. 

-  must  be  present  if  there  is  no  external  document  class  reference  - 
PERM  Specific-layout-structure  {'present'}, 

~  must  be  present  in  the  case  of  complete  document  and  not  present 

in  the  case  of  generic  document 
PERM  Generic-logical-structure  {'complete-generator-sef 

I  partial-generator-set'} . 

-  must  be  present  if  there  is  no  external  document  class  reference  -- 
PERM  Specific-iogical-structure  {'present'}. 

-  must  be  present  in  the  case  of  conrplete  document  and  not  present 
in  the  case  of  generic  document 

PERM  Presentation-styles  {'present'}. 
PERM  Layout-styles  {'present'} 


PERM  External-document-class 
PERM  Resource-document 


{ANY_VALUE}. 
{ANY_VALUE}. 


PERM  Resources 


{MUL  {REQ  #resource-identifier 

REQ  #resource-object -class-identifier 

}. 


{ANY_VALUE}. 
{ANY_VALUE}) 


document  characteristics  - 


REQ  Document-application-profile 


{ -  See  clause  8  for  a  definition  of  the  permitted  values 
for  this  attribute  -}, 


PERM  Document-application-profile-defaults 


CASE  $DAC  OF  { 

$FDA  :{PERM  #content-architecture-class  {$FC|$FPC}} 

$PDA  :  {PERM  #content-architecture-class  {$FC|$PC|$FPC}} 

$FPDA  ;  {PERM  #content-architecture-class  {$FC|$FPC}} 


PERM  #dimensions 
PERM  #medium-type 


{$PermissiblePageDimensions}. 

{PERM  #nominal-page-size  {$NominalPageSizes}, 
PERM  #side-of-sheet  {ANY_VALUE  }}. 


PERM  #transparency 
PERM  #colour 
PERM  #layout-path 
PERM  #block-alignment 
PERM  #border 


{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE}. 
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PERM  #page-posltion  {ANY_VALUE}, 
PERM  #type-of-coding 

{ASN.1  {2  8  360}--  character  encoding  -- 

IASN.1  {2  8  3  7  0}  -  T.6  encoding  - 

IASN.1  {2  8  3  7  1}  -  T.4  one  dimensional  encoding  - 

IASN.1  {2  8  3  7  2}  -  T.4  two  dimensional  encoding  - 

IASN.1  {2  8  3  7  3}  -  bitmap  encoding  ~ 

IASN.1  {2  8  3  8  0}  -  geometric  encoding  -}. 


#character-content-defaults  { 

1  cnivi 

#alignment 

{ANY_VALUE}, 

"cnivi 

#character-fonts 

{ANY_VALUE}, 

#ctiaracter-path 

{ANY  VALUE}. 

r  cnM 

#ctiaracter-spacing 

{ANY_VALUE}, 

r  tnM 

#character-orientation 

{ANY  VALUE}. 

r  tnM 

#code-extension-announcers 

{$DAP-DEFAULT-CDEXTEN}. 

rtnM 

#tirst-line-oftset 

{ANY  VALUE}. 

rtnM 

#graptiic-ctiaracter-sets 

{$DAP-DEFAULT-GRCHAR}. 

r  tnM 

#graptiic-ctiaracter-subrepertoire  { AN Y_V ALU E} , 

PERM 

#graphic- rendition 

{$GRAPHICRENDiTIONS}. 

PERM 

#itemisation 

{ANY  VALUE}. 

PERM 

#kerning-oftset 

{ANY_VALUE}. 

PERM 

#line-layout-table 

{ANY  VALUE}. 

PERM 

#line-progression 

{ANY  VALUE}. 

PERM 

#line-spacing 

{ANY  VALUE}. 

PERM 

#pairwise-kerning 

{ANY_VALUE}. 

PERM 

#indentation 

{ANY_VALUE}. 

PERM 

#orptian-size 

{ANY  VALUE}. 

PERM 

#proportional-line-spacing 

{ANY  VALUE}. 

PERM 

#widow-size 

{ANY  VALUE}. 

PERM 

#formatting-indicator 

{ANY_VALUE}, 

PERM 

#initial-ottset 

{ANY_VALUE} 

PERM  #raster-graptiics-content-detaults  { 

PERM  #pel-path  {ANY_VALUE}, 

PERM  #line-progression  {ANY_VALUE}. 

PERM  #clipping  {ANY_VALUE}. 

PERM  #image-dimensions  {ANY_VALUE}, 

PERM  #pel-spacing  {ANY_VALUE}. 

PERM  #spacing-ratio  {ANY_VALUE}. 

PERM  #compression  {ANY_VALUE} 


PERM  #geometric-graphics-content-defaults  {ANY_VALUE} 

}. 

REQ   Document-arctiitecture-class  {$FDA|  $PDA  |$FPDA}. 

REQ   Content-architecture-classes  {[$FC],[$PC].($FPC],[$FPR].[$FPG]}. 

REQ  Interchange-format-class       { -  See  clause  8  for  the  definition  of  the  permitted  values  for 

this  attribute.  -}. 

REQ   Oda-version  {REQ  #standard-or-recommendation     {"ISO  8613"}, 
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REQ  #publication-date 


{"1992-05-01"}}. 


-  non  basic  document  characteristics  ~ 

PERM  Profile-character-sets  {$PROFCHAR). 

PERM  Comments-character-sets  {SCOMCHAR}. 

PERM  Alternative-representation-character-sets  {$ALTCHAR}. 

PERM  Page-dimensions  {PMUL{$NonBasicPageDimensions}}, 

PERM  Medium-types        {PMUL  {PERM  #nominal-page-size  {SNominalPageSizes}. 

PERM  #side-of-sheet  {'rectoTverso'}}}. 

-  All  values  of  "medium  type"  are  non-basic  - 

PERM  Layout-paths  {{'0-degreesT90-degreesT180-degrees*}...}. 

-  These  values  need  not  to  be  declared,  they  may  be  specified  here  for  upwards  compatibility 
from  FOD26  |  PM-26  -- 

PERM  Borders  {ANY_VALUE}. 

-  Any  values  need  not  to  be  declared,  they  may  be  specKied  here  for  upwards  compatibility 
from  FOD26  |  PM-26  -- 

PERM  Coding-attributes  { 
PERM  #raster-graphics-coding-attributes  { 

PERM  #conpression  {'uncorrpressed'} 

} 

). 

PERM  Presentation-features  { 
PERM  #character-presentation-features  { 

PERM  #character-orientation  {'90-degrees'}. 

-  This  value  needs  not  to  be  declared,  they  may  be  specified  tiere  for  upwards  compatibility 
from  FOD26  |  PM-26  - 

PMUL  {PERM  #character-path  {'90-degreesT180-degreesT270-degrees'}}. 

~  These  values  need  not  to  be  declared,  they  may  be  specified  here  for  upwards 
compatibility  from  FOD26  |  PM-26  - 

PMUL  {PERM  #character-spacing        {<100  1 100  |  160  |  200}}. 

"  These  values  need  not  to  be  declared,  they  may  be  specified  here  for  upwards 
compatibility  from  FOD26  |  PM-26  - 

PMUL  {PERM  #graphic-rendition  {'crossed-outTnot-crossed-out'}}. 

~  These  values  need  not  to  be  declared,  they  may  be  specified  here  for  upwards 
compatibility  from  FOD26  |  PM-26  - 

PMUL  {PERM  #line-spacing     {ANY_VALUE}  EXCEPT{200,  300.  400}}. 

~  Values  100.150  and  600  need  not  to  be  declared,  they  nfiay  be  specified  here  for 
upwards  compatibility  from  FOD26  |  PM-26  -- 

PERM  #line-progression  {'90-degrees'}. 
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--  This  value  needs  not  to  be  declared,  they  may  be  specified  here  for  upwards 
compatibility  from  FOD26  |  PM-26  -- 

PMUL  {PERM  #graphic-character-sets  {$NON-BASIC-GRCHAR}}. 
PMUL  {PERM  #graphic-character-subreper1oire  {ANY_VALUE}} 


PERM  #raster-graphics-presentation-features  { 

PMUL  {PERM  #pel-path  {•90-degreesT180-degreesT270-degrees  }), 

PERM  #line-progression  {'90-degrees'}. 

PMUL  {PERM  #pel-spacing      {ANY_VALUE}EXCEPT{16.  12.  8.  6.  5.  4.  3.  2.  1}}. 
--  Any  value  of  #pel  spaces  is  permitted  as  basic  -- 
-  Basic  values  of  #length  are  multiples  of  #pel  spaces  as  listed  - 


PMUL  {PERM  #spacing-ratio 

{REQ  #line-spacing-value 
REQ  #pel-spacing-value 


{ANY_VALUE}  EXCEPT  {1}. 
{ANY_VALUE}  EXCEPT  {1}}} 


--  additional  document  characteristics 


PERM  Unit-scaling 


PERM  Fonts-list  {PMUL 


{REQ  #unit-scaling-m  {ANY_INTEGER}. 
REQ  #unit-scaling-n  {ANYJNTEGER}}. 

{REQ  #font-identifier  {ANY_VALUE}. 
REQ  #font-reference  {ANY_VALUE}} 


~  document  management  attributes 


-  document  description 
PERM  Title 
PERM  Subject 
PERM  Document-type 
PERM  Abstract 
PERM  Keywords 
REQ  Document-reference 


{ANY_STRING}. 

{ANY_STRING}. 

{ANY_STRING}. 

{ANY_STRING}. 

{ANY_STRING...}. 

{ANY_VALUE}. 


~  dates  and  times  - 

PERM  Document-date-and-time 

PERM  Creation-date-and-time 

PERM  Local-filing-date-and-time 

PERM  Expiry-date-and-time 

PERM  Start-date-and-time 

PERM  Purge-date-and-time 

PERM  Release-date-and-time 

PERM  Revision-history 


{ANY_STRING}. 

{ANY_STRING). 

{ANY_VALUE}, 

{ANY.STRING}. 

{ANY_STRING}. 

{ANY_STRING}, 

{ANY_STRING}. 

{ANY_VALUE}. 


-  originators  ~ 
PERM  Organizations 
PERM  Preparers 
PERM  Owners 
PERM  Authors 


{ANY_STRING...}. 
{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE}. 
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--  other  user  information  -- 
PERM  Copyright 
PERM  Status 
PERM  User-specific-codes 
PERM  Distribution-list 
PERM  Additional-information 

-  external  references  - 

PERM  References-to-other-documents 
PERM  Superseded-documents 

-  local  file  references  - 
PERM  Local-file-references 

-  content  attributes  - 
PERM  Document-size 
PERM  Number-of-pages 
PERM  Languages 

--  security  information  - 
PERM  Authorization 
PERM  Security-classification 
PERM  Access- rights 


7.3  Logical  constituent  constraints 


7.3.1  Macro  definitions 

-  Defines  any  logical  objects  in  a  specific  logical  structure.  - 
DEFINE(LogicalObjects.  " 

<logical-objects>  ::=  OBJECT_ID_OF(DocumentLogicalRoot) 

I  OBJECT_ID_OF(Passage) 
I  OBJECT_ID_OF(NumberedSegment) 
I  OBJECT_ID_OF(Number) 
I  OBJECT_ID_OF(Trtle) 
I  OBJECT_ID_OF(Captlon) 
I  OBJECT_ID_OF(Paragraph) 
I  OBJECT_ID_OF(Phrase) 
I  OBJECT_ID_OF(Footnote) 
I  OBJECT_ID_OF(FootnoteNumber) 
I  OBJECT_ID_OF(FootnoteReference) 
I  OBJECT_ID_OF(FootnoteBody) 
I  OBJECT_ID_OF(FootnoteText) 
I  OBJECT_ID_OF(Figure) 
I  OBJECT_ID_OF(BodyText) 
I  OBJECT_ID_OF(Reference) 
I  OBJECT_ID_OF(ReferencedContent) 
I  OBJECT_ID_OF(BodyRaster) 
I  OBJECT_ID_OF(BodyGeometric) 
I  OBJECT_ID_OF(Descript!on) 
I  OBJECT_ID_OF(Anwork) 


{ANY_VALUE}. 

{ANY_STRING}. 

{ANY_STRING...}. 

{ANY_VALUE}. 

{ANY_VALUE}. 


{ANY_VALUE}. 
{ANY_VALUE}. 


{ AN  Y_  VALUE}. 


{ANYJNTEGER}. 
{ANYJNTEGER}. 
{ANY_STRING  ..}. 


{ANY_VALUE}. 

{ANY_STRING). 

{ANY_STRING...} 
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I  OBJECT_ID_OF(NumberedList) 

I  OBJECT_^ID_OF(UnNumberedList) 

I  OBJECT  ID_OF(DefinitionList) 

I  OBJECT_ID__OF(Listltem) 

I  OBJECT^lD^OF(ListTerm) 

I  OBJECT_ID_OF(Table) 

I  OBJECT^ID_OF(Row) 

I  OBJECT_ID_OF(TableComponent) 

I  OBJECT_  ID_OF(RowComponent) 

I  OBJECT_ID  OF(Form) 

I  OBJECT_ID_OF{EntryElement) 

I  OBJECT_ID_OF(EntryGroup) 

I  OBJECT_ID^OF(EntryText) 

I  OBJECT_ID_OF{EntryRaster) 

I  OBJECT_ID_OF(EntryGeometric); 


--  Defines  any  logical  object  classes  other  than  classes  referred  by  'logical-source' 
DEFINE(LogicalObjectClasses.  " 

<logical-object-classes>  ::=  OBJECT_CLASS_ID_OF(DocumentLogicalRoot) 

I  OBJ ECT_CLASS_ID_OF{ Passage) 
I  OBJECT_CLASS_ID_OF(NumberedSegment) 
I  OBJECT_CLASSJD_OF(Number) 
I  OBJECT_CLASS_ID_OF(Title) 
I  OBJECT_CLASS_ID_OF(Caption) 
I  OBJECT_CLASS_ID_OF(Paragraph) 
I  OBJECT_CLASS_ID_OF(Phrase) 
I  OBJECT_CLASS_ID_OF(Footnote) 
I  OBJECT_CLASS_ID_OF(FootnoteNumber) 
I  OBJECT_CLASS^ID_OF(FootnoteReference) 
I  OBJ ECT_CLASS_I D_OF( FootnoteBody) 
I  OBJECT_CLASS_ID_OF(FootnoteText) 
I  OBJECT_CLASSJD_OF(Figure) 
I  OBJECT_CLASS_ID_OF(BodyText) 
I  OBJECT_CLASS_ID^OF(Reference) 
I  OBJECT  CLASS_ID_OF(ReferencedContent) 
I  OBJECT_CLASS_ID_OF(BodyRaster) 
I  OBJECT_CLASS_ID_OF(BodyGeometric) 
I  OBJECT_CLASS_ID_OF(Description) 
I  OBJ ECT_CLASS_ID_OF( Artwork) 
I  OBJECT_CLASS_ID_OF(NumberedList) 
I  OBJECT_CLASS_ID_OF(UnNumberedList) 
I  OBJECT_CLASS_ID_OF(DefinitionList) 
I  OBJECT_CLASS_ID_OF(Listltem) 
I  OBJECT_CLASS_ID_OF(ListTerm) 
I  OBJECT_CLASS_ID__OF(Table) 
I  OBJECT_CLASS_ID_OF(Row) 
I  OBJECT_CLASS_ID_OF(TableComponent) 
I  OBJECT_CLASS^ID_OF(RowComponent) 
I  OBJECT_CLASS_ID_OF{Form) 
I  OBJECT__CLASS_ID_OF(EntryElernent) 
I  OBJECT_CLASS_ID_OF{EntryGroup) 
I  OBJECT_CLASS_ID_OF(EntryText) 
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i  OBJECT_CLASS_ID_OF(EntryRaster) 
I  OBJECT_CLASS_ID_OF(EntryGeometric); 

') 


DEFINE{N.  vn>::={'"'0"1""rn""2"'T"'3"1"*4"'T"'5""r"'6"n"'^^^^^^ 

any  string  of  characters  from  the  set  of  characters:  '0'...'9'  -- 


Defines  the  prefix  binding.  This  binding  may  be  used  to  associate  a  string  literal  with  an  object 
or  object  class.  In  addition,  this  binding  is  used  to  prefix  text  to  another  binding,  such  as  a 
segment  number,  figure  number,  table  number,  footnote  number  or  page  number.  The 
instances  are  differentiated  by  a  suffix  number.  -- 

DEFINE(PREFIX. 

<prefix>         ::=  '"'prefix-""<n>; 
$N 
") 


Defines  the  suffix  binding.  This  binding  may  be  used  to  associate  a  string  literal  with  an  object 
or  object  class.  In  addition,  this  binding  is  used  to  suffix  text  to  another  binding,  such  as  a 
segment  numt)er.  figure  number,  table  number,  footnote  number  or  page  number.  The 
instances  are  differentiated  by  a  suffix  number.  - 

DEFINE(SUFFIX, 

<suffix>  ;:=  ••"suffix-"''<n>; 

$N 


Defines  the  separator  binding.  This  binding  is  used  to  provide  a  separator  character  for  a 
hierarchical  form  of  a  segment  number,  figure  number,  table  number,  footnote  number  or  page 
number.  The  instances  are  differentiated  by  a  suffix  number. 

DEFINE(SEPARATOR,  " 
<separator>     ::=  "•'separator-""<n>; 
$N 

") 


Defines  the  general  number  binding.  This  binding  may  be  instanced  for  use  as  the  numeric 
value  for  use  such  as  in  segment  number,  figure  number,  table  number,  list  number,  footnote 
numtjer  or  page  number  bindings.  The  instances  are  differentiated  by  a  suffix  numt>er.  -- 

DEFINE(NUMBER. 

<number>       ::=  ""number-""<n>; 
$N 


Defines  the  general  number  string  binding.  This  binding  may  be  instanced  for  use  as  the  string 
value  such  as  for  segment  numfc)er,  figure  number,  table  numfc)er.  list  number,  footnote  number 
or  page  numljers.  The  instances  are  differentiated  by  a  suffix  number.  -- 
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DEFINE(NUMBERSTRING. " 

<numberstring>  ::=  ""numberstring-""<n>; 

$N 
") 


Defines  the  general  string  binding.  The  instances  are  differentiated  by  a  suffix  number.  -- 

DEFINE(STRING,  " 

<string>         ::=  ""string-""<n>; 

$N 
") 


Defines  the  names  for  footnote  categories.  The  instances  are  differentiated  by  a  suffix  number. 


DEFINE(FOOTNOTECATEGORY.  " 

<footnotecategory>      ::=  ""Footnote""[""-""<n>]; 

$N 
") 

DEFINE(INITIALISEBINDINGS,  " 


REQ 

#binding-name 

{$PREFIX}. 

REQ 

#binding-value 

{ANY  STRING} 

|REQ 

#binding-name 

{$SUFFIX}. 

REQ 

#binding-value 

{ANY  STRING} 

|REQ 

#binding-name 

{$SEPARATOR}, 

REQ 

#binding-value 

{ANY  STRING} 

|REQ 

#binding-name 

{$NUMBER}, 

REQ 

#binding-value 

{ANY  INTEGER} 

|REQ 

#binding-name 

{$NUMBERSTR!NG}, 

REQ 

#binding-value 

{ANY  STRING} 

|REQ 

#binding-name 

{$STRING}, 

REQ 

#binding-value 

{ANY  STRING} 

Used  to  make  a  simple  or  compound  string  out  of  the  number  bindings.  -- 

DEFINE(USENUMBERSTRINGS.  " 

REQ  #binding-name  {$NUMBERSTRING}, 

REQ  #binding-value 
{<string-expr>   ::=       <hierarchic-expr>|<simple-expr>  ; 

<hierarchic-expr>        ;:=  B_REF(SUP(CURR-OBJ))(<numberstring>) 

B_REF(SUP(CURR-OBJ)){<separator>) 
<simple-expr>; 

<simple-expr>  ::=  MK-STR(B_REF(CURR-OBJ){<number>)) 
I  U-ALPHA(B_REF(CURR-OBJ)(<number>)) 
I  L-ALPHA(B_REF(CURR-OBJ)(<number>)) 
I  U-ROM(B_REF(CURR-OBJ)(<number>)) 
I  L-ROM(B_REF(CURR-OBJ)(<number>)) 
I  MK-STR(ORD(CURR  OBJ)) 
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I  U-ALPHA(ORD(CURR-OBJ)) 
I  L-ALPHA(ORD{CURR-OBJ)) 
I  U-ROM(ORD(CURR-OBJ)) 
I  L-ROM(ORD(CURR-OBJ)) 
I  ANY_STRING; 

$NUMBERSTRING 

$SEPARATOR 

$NUMBER} 

") 


Used  to  increment  any  of  the  number  bindings.  -- 

DEFINE(USENUMBERS,  " 

REQ  #binding-name  {$NUMBER}, 
REQ  #binding-value 

{<num-expr>  ::=  INC{B_REF(PREC(CURR-OBJ))(<number>)); 

$NUMBER} 
") 

Used  to  initialise/specify  or  manipulate  the  bindings.  The  bindings  defined  by  this  macro  are 
permitted  to; 

any  logical  object  class. 

any  logical  object, 

any  layout  object  class  except  frame  classes  and  block  classes. 


DEFINE{SPECIFYBINDINGS.  " 

$INITIALISEBINDINGS  |  $USENUMBERS  |  $USENUI^BERSTRINGS 
") 


Used  to  initialise  fnotenumber  and  fnotestring  bindings.  -- 

Note  that  footnote  numbehng  is  realized  as  a  particular  case  of  the  general  number  binding 
mechanism  supported  by  this  DAP  using  the  bindings  <number>  and  <nunnberstring>. 
"fnotenumber"  and  "fnotestring"  may  be  used  for  the  compatibility  with  FOD26  |  PM-26.  -- 


DEFINE(INITIALISEFNOTE.  " 

REQ  #binding-name  {"'Inotenumber"), 
REQ  #binding-value  {>=0} 

") 


--  Used  to  increment  fnotenumber  binding.  -- 

DEFINE(INCFNOTENUMBER," 

REQ  #binding-name  {""fnotenumber""}, 
REQ  #binding-value 

{<num-expr>  ::=  INC(B_REF(PREC{CURR-OBJ))nnotenumber"));} 

") 
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j--        Used  to  create  a  fnotestring  from  a  fnotenumber  binding.  -- 

j 

DEFINE(FNOTENUMBERSTRING,  " 

REQ  #binding-name  {""fnotestring""}, 
REQ  #binding-vaiue  {<str-expr>:;= 

MK-STR(B_REF(CURR-OBJ)rfnotenumber")) 
I  U-ALPHA(B_REF(CURR-OBJ)(""fnotenumber"")) 
I  L-ALPHA(B_REF(CURR-OBJ)("'1notenumber"")) 
I  U-ROM(B_REF(CURR-OBJ)(""fnotenumber"")) 
I  L-ROM(B_REF(CURR-OBJ)(""fnotenumber""));} 


Used  to  reset  the  footnote  number  string  to  a  string  literal.  This  provides  a  mechanism  for 
setting  the  footnote  number  string  to  something  other  than  a  numeric  value.  -- 

DEFINE(FNOTESTRINGLITERAL,  " 

REQ  #binding-name  (""fnotestring""}, 
REQ  #binding-value  (ANY_STRING} 

") 


Used  to  initialise  PGnum  binding.  -- 

Note  that  a  page  numbering  is  realized  as  a  particular  case  of  the  general  number  binding 
mechanism  supported  by  this  DAP  using  the  bindings  <number>  and  <numberstring>.  "PGnum" 
may  be  used  for  the  compatibility  with  FOD26  |  PM-26.  -- 

DEFINE{INITIALISEPGNUMBER,  " 

REQ  #binding-name  {""PGnum""}, 
REQ  #binding-value  {>=-1} 

") 


Used  to  increment  PGnum  binding.  -- 

DEFINE(USEPGNUMBERS," 

REQ  #binding-name  {""PGnum""}, 

REQ  #binding-value  {<num-expr>::=  INC{B_REF(PREC(CURR-OBJ))rPGnum""));} 

") 


This  string  expression  is  allowed  in  a  content  generator  for  Number  to  automatically  generate 
text  for  segment  numbers,  figure  numbers  or  list  numbers.  (Note:  B_REF(CURR-OBJ)  is  used 
for  list  numbers.)  -- 

DEFINE(SEGMENTNUMBER,  " 
<string-expr>    :;=  (<pre-str>]<num-str>[<suf-str>]; 
<num-str>  ::=  B_REF(SUP(CURR-OBJ))(<numberstring>) 

I  B_REF(CURR-OBJ)(<numberstnng>); 
<pre-str>  ::=       B_REF(SUP(CURR-OBJ))(<prefix>)  |  ANY_STRING; 

<suf-^tr>  ::=       B_REF(SUP(CURR-OBJ))(<suffix>)  |  ANY_STRING; 

$NUMBERSTRING 
SPREFIX 
$SUFFIX 
") 
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This  string  expression  is  allowed  in  a  content  generator  for  TableNumber  to  automatically 
generate  text  for  a  table  numt)er.  - 


DEFINE(TABLENUMBER.  " 

<string-expr>   ::=  [<pfe-str>]<num-str>(<suf-str>]; 
B_REF 

(CURR-INST(OBJECT_CLASSJD_OF(Table).(CURR-OBJ))) 
(<numberstring>); 
::=  B_REF(SUP 

(CURR-INST(OBJECT_CLASS_ID_OF{Table).(CURR-OBJ)))) 
(<prefix>) 
!  ANY_STRING: 
::=  B_REF(SUP 

(CURR-INST{OBJECT_CLASS_ID_OF(Table),(CURR-OBJ)))) 
(<suffix>) 
I  ANY_STRING; 

SNUMBERSTRING 
SPREFIX 
SSUFFIX 
") 


<num-str> 


<pre-str> 


<suf-str> 


Ttiis  string  expression  is  allowed  in  a  content  generator  for  PageNumber  to  automatically 
generate  text  for  a  page  nurrtDer.  -- 

Note  that  a  page  number  may  be  generated  either  from  <number>  or  <numberstring>  or  from 
PGnum.  PGnum  is  kept  for  the  compatibility  with  FOD26  |  PM-26.  -- 

DEFINE(PGNUMBER. 


<string-expr> 

<pre-str> 

<suf-str> 

<num-str> 


=  (<pre-str>]<num-str>(<suf-str>]; 

=  B_REF(SUP(<current-layout-object>))(<prefix>)  |  ANY_STRING; 
=  B_REF(SUP(<current-layout-object>))(<suffix>)  |  ANY_STRING; 

:=  MK-STR(<numeric-expr>) 
j  U-ALPHA(<numeric-expr>) 
I  L-ALPHA(<numeric-expr>) 
I  U-ROM(<numeric-expr>) 
I  L-ROM(<numerlc-expr>) 
I  B_REF(SUP(<layout-object-1  >))(<numberstrlng>) 
I  B_REF(<layout-object-2>)(<numtDerstring>); 


<numeric-expr> 


::=  B_REF(SUP(<layout-object-1>))(<number>) 
B_REF(SUP(<layout-object-1>))rPGnum"") 
B_REF(<layout-object-2>){<number>) 
B_REF(<layout-object-2>)("**PGnum-'); 


<current-layout-object> 

<layout-object-1> 

<layout-object-2> 

<class-or-type-1> 

<class-or-type-2> 


SPREFIX 


:=  <layout-object-1>  |  <layout-object-2>; 

:=  CURR-INST(<class-or-type-1  >.(CURR-OBJ)); 

:=  CURR-INST(<class-or-type-2>.(CURR-OBJ)); 

:=  'frame'; 

:=  page" 

I  OBJECT_CLASS_ID_OF(Page) 

I  OBJECT_CLASS_ID_OF{RectoPage) 

I  OBJECT_CLASS_ID_OF(VersoPage); 
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PSUFFIX 

(NUMBER 

iNUMBERSTRING 

I 


This  string  expression  is  allowed  in  a  content  generator  for  FootnoteNumber  and 
FootnoteReference  to  automatically  generate  text  for  a  footnote  number.  -- 
Note  that  a  footnote  number  may  be  generated  either  from  <numberstring>  or  from 
"fnotestring".  "fnotestring"  is  kept  for  the  compatibility  with  FOD26  |  PM-26. 


)EFINE(FNNUMBER.  " 

<string-expr> 

<num-str> 


<pre-str> 
<suf-str> 

$NUMBERSTRING 

$PREFIX 

SSUFFIX 


[<pre-str>]<num-str>[<suf-str>]; 

::=  B_REF(SUP(CURR-OBJ))(<numberstring>) 

I  B_REF(SUP(CURR-OBJ))(""fnotestring"") 

I  ANY_STRING; 
::=  B_REF(SUP(CURR-OBJ))(<prefix>) 

I  ANY_STRING; 
:;=  B_REF(SUP(CURR-OBJ))(<suffix>) 

I  ANY_STRING: 


This  string  expression  is  allowed  in  a  content  generator  for  ReferencedContent  to  automatically 
generate  text  for  references  such  as  to  segment  numbers,  table  numbers,  figure  numbers,  list 
numbers,  footnote  numbers  and  <string>  bindings  associated  with  a  referring  (i.e.  a  target) 
logical  object,  or  to  page  numbers,  pageset  numbers  and  <sthng>  bindings  associated  with  a 
layout  object  in  which  the  referring  logical  object  is  laid  out.  -- 

DEFINE(REF.  " 

<string-expr>  ::=  (<pre-str>]<ref-str>[<suf-str>]; 

These  are  a  prefix  and  a  suffix  of  ReferencedContent  itself,  not  those  of  referring  text.  e.g. 
(See'  and ')'.  - 

<pre-str>  ::=  B_REF(SUP(CURR-OBJ))(<prefix>)  |  ANY_STRING; 
<suf-str>         ::=  B_REF(SUP(CURR-OBJ))(<suffix>)  |  ANY_STRING; 


j  <ref-str>         ::=  {  <ref-numberstring> 

I  <ref-fnotestring> 
<  I  <ref-pgnum> 

,  I  <ref-number> 

I  I  <ref-string> 

I  ANY_STRING  }...  ; 

I  <ref-numberstring>  ::=  [<pre-str-a>]  <ref-str-a>  [<suf-str-a>]; 

<pre-str-a>  ::=  B_REF(SUP(<target-object-1>))(<prefix>) 
y  I  B_REF(<target-object>)(<prefix>)  ; 

I  <suf-str-a>  ::=  B_REF(SUP(<target-object-1>))(<suffix>) 
I  B_REF(<target-object>)(<suffix>)  ; 
<ref-str-a>  ::=  B_REF(SUP(<target-object-1>))(<numberstring>) 
I  B_REF(<target-object>)(<numberstring>); 
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<ref-fnotestring>  ;:=  [<pre-str-b>]  <ref-str-b>  [<suf-str-b>]; 
<pre-str-b>  ::=  B_REF(SUP(<target-logical-object-1>))(<prefix>) 

I  B_REF(<target-logical-object>)(<pretix>)  ; 
<suf-str-b>  ::=  B_REF(SUP(<target-logica!-object-1>))(<suftix>) 

I  B_REF(<target-logical-object>)(<suttix>)  ; 
<ref-str-b>  :.=  B_REF(SUP^<target-logical-object-1  >))("'1notestring"") 

I  B_REF(<target-logical-object>)(""fnotestring""); 

<ref-pgnum>  ::=  (<pre-str-€>]  <ref-str-c>  [<suf-str-c>]; 
<pre-str-c>  ::=  B_REF(SUP(<target-layout-object>))(<prefix>)  ; 
<suf-str-c>  ::=  B_REF{SUP(<target-layout-object>))(<suftix>)  ; 
<ref-str-c>  ::=  MK-STR(B_REF(SUP(<layout-object-1>))rPGnum"")) 

I  U-ALPHA(B_REF(SUP(<layout-object-1>))(""PGnum"")) 

I  L-ALPHA(B_REF(SUP(<layout-object-1  >))(""PGnum"")) 

!  U-ROM(B_REF(SUP(<layout-object-1>))(""PGnum"")) 
I  L-ROM{B_REF(SUP(<layout-object-1>))rPGnum"")) 
I  MK-STR(B_REF(<layout-object-2>)r"PGnum"")) 

I  U-ALPHA(B_REF(<layout-ob)ect-2>)(""PGnum"")) 
I  L-ALPHA(B_REF(<layout-object-2>)rPGnum"")) 
I  U-ROM(B_REF(<layout-object-2>)(""PGnum"")) 
I  L-ROM(B_REF(<layout-object-2>)(""PGnum"")); 

<ref-number>  ;;=  [<pre-str-d>]  <ref-str-d>  [<suf-str-d>]; 
<pre-str-d>  ::=  B_REF(SUP(<target-object-1>))(<prefix>) 

I  B_REF(<target-object>)(<prefix>)  ; 
<suf-str-d>  ;;=  B_REF(SUP{<target-obiect-1>))(<suffix>) 

I  B_REF(<target-object>)(<sutfix>)  ; 
<ref-str-d>  :;=  MK-STR(B_REF{SUP{<target-object-1>))(<number>)) 

I  U-ALPHA(B_REF(SUP(<target-object-1>))(<number>)) 

I  L-ALPHA(B_REF(SUP(<target-object-1  >))(<number>)) 

I  U-ROM(B_REF(SUP(<target-object-1  >))(<number>)) 

I  L-ROM(B_REF(SUP(<target-object-1>)){<number>)) 

I  MK-STR(B_REF(<target-object>)(<number>)) 

I  U-ALPHA(B_REF(<targel-object>)(<number>)) 

I  L-ALPHA(B_REF(<target-object>){<number>)) 

I  U-ROM(B_REF(<target-object>)(<number>)) 

I  L-ROM(B_REF(<target-object>)(<number>)); 

<ref-string>  ::=  [<pre-str-e>]  <ref-str-e>  [<suf-str-e>]; 
<pre-str-e>  ::=  B_REF(SUP(<target-object-1  >))(<prefix>) 

I  B_REF(<target-object>)(<prefix>)  ; 
<suf-str-e>  ::=  B_REF{SUP(<target -object- 1>))(<suftix>) 

I  B_REF(<target-object>)(<suftix>)  ; 
<ref-str-e>  ::=  B_REF(SUP(<target-object-1>))(<string>) 

I  B_REF(<target-object>)(<string>), 

<target-object>  :;=  <target-logical-object>  |  <target-layout-object>; 
<target-object-1>  ::=  <target-logical-object-1>  |  <target-layout-object>; 

<target-logical-object>  ;:=  <logical-objects>  |  CURR-INST(<class-or-type-logical>.<logical-objects>); 
<target-logical-object-x>  ::=  <logical-objects>  |  CURR-INST(<class-or-type-logical>,<logical-objects>)); 
<target-logical-object-1  >  ::=  CURR-INST(<class-or-type-logical>,<logical-objects>); 
<class-or-type-logical>  ::=  <logical-object-classes> 

I  'composite-logical-object' 

I  'basic-logical-object'; 
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<target-layout-object>  ::=  <layout-object-1>  |  <layout-object-2> ; 
<layout-object-1>  ::=  CURR-INST(<class-or-type-layout-1>,<target-logical-object-x>); 
<layout-object-2>  ::=  CURR-INST(<class-or-type-layout-2>,<target-logical-object-x>); 
<class-or-type-layout-1>  :  <class-or-type-layout-1>  ::=  'frame'; 
<class-or-type-layout-2>  ::=  'page' 

I  OBJECT_CLASS_ID_OF(Page) 

I  OBJECT_CLASS_ID_OF(RectoPage) 

I  OBJECT_CLASS_ID_OF(VersoPage); 

$PREFIX 
SSUFFIX 

$NUMBERSTRING 
$NUMBER 
$STRING 
$LogicalObjects 
$LogicalObjectClasses 
") 


This  string  expression  is  allowed  in  a  content  generator  for  CommonReference  to  automatically 
generate  text  for  references  such  as  to  segment  numbers,  table  numbers,  figure  numbers,  list 
numbers,  footnote  numbers  and  <string>  bindings  associated  with  a  logical  object  which  is  laid 
out  in  a  current  layout  object,  or  to  page  numbers,  pageset  numbers  and  <string>  bindings 
associated  with  a  current  or  a  superior  layout  object.  -- 

DEFINE(COMMONREF,  " 
<string-expr>    :;=  [<pre-str>]<ref-str>[<suf-str>]; 

<pre-str>  ::=  B_REF(SUP(<current-layout-object>))(<prefix>)  |  ANY_STRING; 
<suf-str>        ::=  B_REF(SUP(<current-layout-object>))(<suffix>)  |  ANY_STRING; 

<ref-str>         ::=  {  <ref-numberstring> 
I  <ref-fnotestring> 
I  <ref-pgnum> 
I  <ref-number> 
I  <ref-string> 
I  ANY_STRING    }  ...  ; 

<ref-numberstring>  ::=  [<pre-str-a>]  <ref-str-a>  [<suf-str-a>]; 
<pre-str-a>  ::=  B_REF(SUP(<current-object>))(<prefix>) 

I  B_REF(<current-object>)(<prefix>)  ; 
<suf-str-a>  :;=  B_REF(SUP(<current-object>))(<suffix>) 

I  B_REF(<current-object>)(<suffix>)  ; 
<ref-str-a>  :;=  B_REF(SUP(<current-object>))(<numberstring>) 

I  B_REF(<current-object>){<numberstring>); 

<ref-fnotestring>  ;:=  [<pre-str-b>]  <ref-str-b>  [<suf-str-b>]; 
<pre-str-b>  ::=  B_REF{SUP(<current-logical-object>))(<prefix>) 

I  B_REF(<cun'ent-logical-object>){<prefix>)  ; 
<suf-str-b>  ::=  B_REF(SUP(<current-logical-object>))(<suffix>) 

I  B_REF(<current-logical-object>)(<suffix>)  ; 
<ref-str-b>  :.=  B_REF(SUP(<current-logical-object>))(""fnotestring"") 

I  B_REF(<current-logical-object>)(""fnotestring""); 

<ref-pgnum>  :  -  [<pre-str-c>]  <ref-str-c>  [<suf-str-c>]; 
<pre-str-c>     B_REF{SUP(<current-layout-object>))(<prefix>)  ; 


139 


<suf-str-c>  ::=  B_REF(SUP(<current-layout-object>))(<suffix>)  ; 

<ref-str-c>  ::=  MK-STR(B_REF(SUP(<layout-object-1>))rPGnum"")) 
I  U-ALPHA(B_REF(SUP(<layout-object-1>))rPGnum*~)) 
I  L-ALPHA(B_REF(SUP(<layout-object-1  >))rPGnum"")) 
I  U-ROM(B_REF(SUP(<layout-object-1  >))rPGnum"")) 
I  L-ROM(B_REF(SUP(<layout-object-1  >))rPGnum"")) 
I  MK-STR(B_REF(<layout-object-2>)(""PGnum-*)) 
j  U-ALPHA(B_REF(<layout-object-2>)(""PGnum"")) 
I  L-ALPHA(B_REF(<layout-object-2>)r"PGnum"")) 
I  U-ROM(B_REF(<layout-object-2>)C*"PGnum"")) 
I  L-ROM(B_REF(<layout-object-2>)(""PGnum*"')); 

<ref-number>  ::=  (<pre-str-d>]  <ref-str-d>  (<suf-str-d>]; 

<pre-str-d>  ::=  B_REF{SUP(<current-object>))(<prefix>) 
j  B_REF(<current-object>){<prefix>)  ; 

<suf-str-d>  ::=  B_REF(SUP(<current-object>))(<suffix>) 
I  B_REF(<current-object>)(<sutfix>)  ; 

<ref-str-d>  ::=  MK-STR(B_REF(SUP(<current-object>))(<number>)) 
I  U-ALPHA(B_REF(SUP(<current-object>))(<number>)) 
I  L-ALPHA(B_REF(SUP(<airrent-object>))(<number>)) 
I  U-ROM(B_REF(SUP(<current-object>))(<number>)) 
!  L-ROM(B_REF(SUP(<current-object>))(<number>)) 
I  MK-STR(B_REF(<current-object>)(<number>)) 
I  U-ALPHA(B_REF(<current-object>)(<number>)) 
I  L-ALPHA(B_REF{<current-object>)(<number>)) 
I  U-ROM(B_REF(<current-object>)(<number>)) 
I  L-ROM(B_REF(<current-object>)(<number>)); 

<ref-string>  ::=  {<pre-str-e>]  <ref-str-e>  [<suf-str-e>]; 
<pre-str-e>  ::=  B_REF(SUP(<current-object>))(<prefix>) 

I  B_REF(<current-object>){<prefix>)  ; 
<suf-str-e>  :;=  B_REF(SUP(<current-object>))(<suftix>) 

I  B_REF(<curTent-object>)(<suffix>)  ; 
<ref-str-e>  ::=  B_REF(SUP(<current-object>)){<string>) 

I  B_REF(<current-object>)(<string>) ; 


<current-object>  ::=  <current-togical-object>  |  <current-layout-object>; 

<current-logical-object>  ::=  CURR-INST(<class-or-type-logical>.(CURR-OBJ)); 
<class-or-type-logical>  ::=  <logical-object-classes> 

I  composite-logical-objecf 

I  basic-logical-objecf; 


<current-layout-object>  ::=       <layout-object-1>  |  <layout-object-2>; 

<layout-object-1>  ::=  CURR-INST(<class-or-type-layout-1  >,(CURR-OBJ)); 

<layout-object-2>  ::=  CURR-INST(<class-or-type-layout-2>.(CURR-OBJ)); 

<class-or-type-layout-1>  ::=  'frame'; 

<class-or-type-layout-2>  ::=  page" 

I  OBJECT_CLASS_ID_OF(Page) 

I  OBJECT_CLASS_ID_OF(RectoPage) 

I  OBJECT_CLASS_ID_OF(VersoPage); 


SPREFIX 
$SUFFIX 

SNUMBERSTRING 
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$NUMBER 
$STRING 

$LogicalObjectC  lasses 
") 

This  string  expression  is  allowed  in  a  content  generator  for  CommonNumber  to  automatically 
generate  text  for  general  references  to  any  kinds  of  numbers  including  segment  numbers,  table 
numbers,  figure  numbers,  list  numbers,  footnote  numbers,  page  numbers  or  pageset  numbers, 
etc.  -- 

DEFINE(COf^MONNUMBER,  " 
<string-expr>   :;=  <ref-numberstring> 
I  <ref-number>; 

<ref-numberstring>  ::=  [<pre-str-a>]  <ref-str-a>  I<suf-str-a>]; 
<pre-str-a>  ::=  B_REF(SUP(<current-object>))(<prefix>) 

I  B_REF{<current-object>){<prefix>)  |  ANY_STRING; 
<suf-str-a>  :;=  B_REF(SUP(<current-object>))(<suffix>) 

I  B_REF(<current-object>)(<suffix>)  |  ANY_STRING; 
<ref-str-a>  ::=  B_REF(SUP(<current-object>))(<numberstring>) 

I  B_REF(<current-object>)(<numberstring>); 

<ref-number>  ;:=  (<pre-str-b>]  <ref-str-b>  [<suf-str-b>]; 
<pre-str-b>  ::=  B_REF{SUP(<current-object>))(<prefix>) 

I  B_REF(<current-object>)(<prefix>)  |  ANY_STRING; 
<suf-str-b>  ::=  B_REF(SUP(<current-object>))(<suffix>) 

I  B_.REF(<current-obiect>)(<suffix>)  |  ANY_STRING; 
<ref-str-b>  ::=  Mk-STR(B_REF(SUP(<current-object>))(<number>)) 


I  U-ALPHA(B_REF(SUP(<current-object>))(<number>)) 
I  L-ALPHA(B_REF(SUP(<current-object>)){<number>)) 
I  U-ROf\^(B_REF(SUP(<current-object>)){<number>)) 
I  L-ROM(B_REF(SUP(<current-object>))(<number>)) 
I  MK-STR(B_REF(<current-object>)(<number>)) 
I  U-ALPHA(B_REF(<current-object>)(<number>)) 
I  L-ALPHA(B_REF(<current-object>)(<number>)) 
I  U-ROt^(B_REF(<current-object>)(<number>)) 
I  L-ROM(B_REF(<current-object>)(<number>)); 


<current-object> 


::=  <current-logical-object>  ]  <current-layout-object>; 


<current-logical-object> 
<class-or-type-logical> 


;=  CURR-INST(<class-or-type-logical>.(CURR-OBJ)); 
;=  <logical-object-classes> 

I  'composite-logical-object' 

I  'basic-logical-object'; 


<current-layout-object> 
<class-or-type-layout> 


;=  CURR-INST(<class-or-type-layout>.(CURR-OBJ)); 
:=  'frame' 
I  page" 

I  OBJECT_CLASSJD_OF(Page) 

I  OBJECT_CLASS_ID_OF(RectoPage) 

I  OBJECT_CLASS_ID_OF(VersoPage); 


$PREFIX 
$SUFFIX 
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$NUMBERSTRING 
SNUMBER 

$LogicalObjectClasses 
") 


This  string  expression  is  allowed  in  a  content  generator  for  Currentlnstance  to  automatically 
generate  text  for  general  references  to  <string>  bindings  associated  with  a  current  logical  or 
layout  object.  -- 

DEFINE(CURRENTINSTANCE.  " 
<string-expr>   ::=  [<pre-str>]<ref-str>(<suf-str>); 
<pre-str>        ::=  B_REF(SUP(<current-object>))(<prefix>) 

I  B_REF(<cun-ent-object>)(<prefix>)  |  ANY_STRING; 
<suf-str>         ::=  B_REF(SUP(<current-object>))(<suffix>) 

I  B_REF(<cun^ent-object>){<suffix>)  |  ANY_STRING; 
<ref-str>         ::=  B_REF(SUP(<current-object>))(<string>) 

I  B_REF(<current-object>)(<string>); 

<current-object>         :.=  <current-logical-object>  |  <current-layout-object>; 

<cun'ent-logical-object>  ::=  CURR-INST(<class-or-type-logical>.(CURR-OBJ)); 

<class-or-type-logical>  .:=  <logical-object-classes> 

I  'composite-logical-object' 

I  basic-logical -object'; 

<cun-ent-layout-object>  ::=  CURR-INST(<class-or-type-layout>,(CURR-OBJ)); 

<class-or-type-layout>  ;:=  frame' 

I  "page- 

I  OBJECT_CLASS_ID_OF(Page) 

I  OBJECT_CLASS_ID_OF(RectoPage) 

I  OBJECT_CLASSJD_OF(VersoPage); 

$PREFIX 
SSUFFIX 
$STRING 

$LogicalObjectClasses 
") 


This  string  expression  is  allowed  in  a  content  generator  for  GenericBlock  to  automatically 
generate  text  for  general  references  to  bindings  associated  with  a  current  layout  object.  - 

DEFINE(GENERICBLOCKREF.  " 
<string-expr>    ::=  [<pre-str>]<ref-str>(<sut-str>]; 

<pre-str>  ::=  B_REF(SUP(CURR-OBJ))(<prefix>)  |  ANY_STRING; 
<suf-str>         ::=  B_REF(SUP(CURR-OBJ))(<suttix>)  |  ANY_STRING; 

<ref-str>         ::=  fy/IK-STR(B_REF(SUP(CURR-OBJ))(<number>)) 
I  U-ALPHA(B_REF(SUP(CURR-OBJ))(<number>)) 
I  L-ALPHA(B_REF(SUP(CURR-OBJ))(<number>)) 
I  U-ROM(B_REF(SUP(CURR-OBJ))(<number>)) 
I  L-ROM(B_REF(SUP(CURR-OBJ))(<number>)) 
I  MK-STR(B_REF(SUP(CURR-OBJ))(""PGnum"")) 
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I  U-ALPHA(B_REF(SUP(CURR-OBJ))(-PGnum"")) 
I  L-ALPHA(B_REF(SUP(CURR-OBJ))rPGnum"")) 
I  U-ROM(B_REF(SUP(CURR-OBJ))(-PGnum"")) 
I  L-ROM(B_REF(SUP(CURR-OBJ))(""PGnum"")) 
I  B_REF(SUP(CURR-OBJ))(<numberstring>) 
I  B_REF(SUP(CURR-OBJ))(<string>); 

SPREFIX 
SSUFFIX 
$NUMBER 
$NUMBERSTRING 
SSTRING 
") 


DEFINE(DocLogRootGFS, 
<constnjction-expr>  ::= 


«X)nstruction-term> 


<construction-type> 


<construction-factor; 


<cx)nstruction-term> 

I  <construction-type>; 

<construction-factor> 

I  OPT  <construction-factor> 
I  REP  <construction-faclor> 
I  OPT  REP  <construction-factor>; 

SEQ({<construction-term>}. . .) 

I  CHO({<construction-term>}...); 

OBJECT_CLASS_ID_OF(Passage) 

I  OBJECT_CLASS_ID_OF(NumberedSegment) 
I  <construction-type>; 


DEFINE(C0NSTRAINT-1, 
<constraint-1> 


<construction-term> 


<construction-type> 
<construction-factor> 


<construction-term> 

I  <construction-type>; 

<construction-factor> 

I  OPT  <construction-factor> 
I  REP  <construction-factor> 
I  OPT  REP  <construction-factor>; 

SEQ({<construction-term>}...) 

I  CHO({<construction-term>}...); 

OBJECT_CLASS_ID_OF(Passage) 

I  OBJECT_CLASS_ID_OF(NumberedSegment) 

I  OBJECT_CLASS_ID_OF(Paragraph) 

I  OBJECT_CLASS_ID_OF(BodyText) 

I  OBJECT_CLASS_ID_OF(BodyRaster) 

I  OBJECT_CLASS_ID_OF(BodyGeometric) 

I  OBJECT_CLASS_ID_OF(Figure) 

I  OBJECT_CLASS_ID_OF(Table) 

I  OBJECT_CLASS_ID_OF{NumberedList) 

I  OBJECT_CLASS_ID_OF(UnNumberedList) 

I  OBJECT_CLASSJD_OF(DefinitionUst) 
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I  <constnjction-type>; 


DEFINE(C0NSTRAINT-2.  " 
<constraint-2>  ::=  - 

") 


DEFINE(PassageGFS. " 
<cx)nstnjction-expr>     ::=  <constraint-1> 

I  SEQ(<constraint-2><constraint-1  >); 

$C0NSTRAINT-1 
$C0NSTRAINT-2 

1 


DEFINE(NumberedSegmentGFS, " 
<construction-expr>  ::= 

SEQ(<term-1>(<constraint-2>][<constraint-1>]); 

<term-1>  ::=  OBJECT_CLASS_ID_OF(Number); 

$C0NSTRAINT-1 
$C0NSTRAINT-2 
••)  - 


DEFINE(CONSTRAINT-3. 
<construction-expr> 


<construction-term> 


<construction-type> 


<construction-factor> 


DEFINE(ParagraphGFS.  "$CONSTRAINT-3") 


OBJECT_CLASS_ID_OF(Title) 

I  OPT  OBJECT_CLASS_ID_OF(Title); 


<construction-term> 

I  <construction-type>; 

<construction-factor> 

I  OPT  <construction-tactor> 
I  REP  <construction-factor> 
I  OPT  REP  <constaiction-factor>; 

SEQ({<construction-term>}...) 

I  CHO({<construction-term>}...); 

OBJECT_CLASS_ID_OF(BodyText) 

I  OBJECT_CLASS_ID_OF(BodyRaster) 
I  OBJECT_CLASS_ID_OF(BodyGeometric) 
I  OBJECT_CLASS_ID_OF(Footnote) 
I  OBJECT_CLASS_ID_OF(Phrase) 
I  OBJECT_CLASS_ID_OF(Reference) 
I  «X)nstruction-type>; 
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DEFINE(TitleGFS.  "$C0NSTRAINT-3") 


pEFINE(FigureGFS.  " 

<construction-expr>  :.= 

SEQ([<term-1>l[<term-2>]{<term-3>]<term-4>) 
I  SEQ([<term-1  >](<term-2>]<term-4>[<term-3>]) 
I  SEQ(I<term-3>][<term-1  >]I<term-2>]<term-4>) 
I  SEQ(<term-4>[<term-1  >](<term-2>l[<term-3>]) 
I  SEQ((<term-3>]<term-4>(<term-1  >][<term-2>]) 
I  SEQ(<term-4>(<term-3>][<term-1  >][<term-2>]); 


<term-1> 
<term-2> 
<term-3> 
<term-4> 


OBJECT_CLASS_ID_OF(Number) 

I  OPT  OBJECT_CLASSJD_OF(Number); 

OBJECT_CLASS_ID_OF(Caption) 

I  OPT  OBJECT_CLASS_ID_OF(Caption); 

OBJECT_CLASS_ID_OF(Description) 

I  OPT  OBJECT_CLASS_ID_OF(Description); 

OBJECT_CLASS_ID_OF(Artwork) 

I  OBJECT_CLASSJD_OF(Form); 


DEFINE(ArtworkGFS. " 
<construction-expr> 


<construction-term> 


<construction-term> 

I  <construction-type>; 

<construction-factor> 

I  OPT  <construction-factor> 
I  REP  <construction-factor> 
I  OPT  REP  <construction-factor>; 


<construction-type> 


<construction-factor>  ::= 


") 


SEQ({<construction-term>}. . .) 

I  CHO({<construction-term>}. 


•); 


OBJECT_CLASS_ID_OF(Phrase) 

I  OBJECT_CLASS_ID_OF(BodyRaster) 
I  OBJECT_CLASS_ID_OF(BodyGeometric) 
1  <construction-type>; 


DEFINE(C0NSTRAINT-5. 
<construction-expr>  ::= 


<construction-term> 


<constaiction-type> 


<construction-term> 

I  <construction-type>; 

<construction-factor> 

I  OPT  <construction-factor> 
I  REP  <construction-factor> 
I  OPT  REP  <construction-factor>; 

SEQ({<construction-term>}...) 

I  CHO({<construction-term>}...); 


<construction-factor>    ::=  OBJECT_CLASS_ID_OF(Phrase) 
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I  OBJECT_CLASS_ID_OF(Footnote) 
I  OBJECT_CLASS_iD_OF{Reference) 
I  OBJECT_CLASS_ID_OF(BodyText) 
I  <construction-type>; 


DEFINE(PhraseGFS.  "$C0NSTRAINT-5") 


DEFINE(CaptionGFS,  "$C0NSTRAINT-5") 


DEFINE(DescriptionGFS.  "$C0NSTRAINT-5") 


DEFINE(FootnoteGFS.  " 
<construction-expr>  ::= 

SEQ(OBJECT_CLASS_ID_OF(FootnoteReference) 
OBJECT_CLASSJD_OF(FootnoteBody)); 


DEFINE(FootnoteBodyGFS, 
<construction-expr>  ;:= 


SEQ(OBJECT_CLASS_ID_OF(FootnoteNumber) 
<term-1>); 


<term-1> 


OBJECT_CLASS_ID_OF(FootnoteText) 

I  OBJECT_CLASS_ID_OF(Reference) 

I  REP  OBJECT_CLASS_ID_OF(FootnoteText) 

I  REP  OBJECT_CLASS_ID_OF(Reference) 

I  CHO({OBJECT_CLASS_ID_OF(FootnoteText) 

I  OBJECT_CLASS_ID_OF(Ref erence)} . . .) 
I  REP  CHO({OBJECT_CLASS_ID_OF(FootnoteText) 

I  OB  J  ECT_C  L  ASS_I  D_0  F  ( Ref  e  re  nee) } . . . ) : 


DEFINE(ReferenceGFS. " 

<construction-expr>     ::=  OBJECT_CLASS_ID_OF(ReferencedContent) 

I  SEQ([<term>] 

OBJECT_CLASS_ID_OF(ReferencedContent) 
[<term>]); 

<term>  ::=  OBJECT_CLASS_ID_OF(BodyText) 

I  OPT  OBJECT_CLASS_ID_OF(BodyText) 

I  CHO(  {OBJECT_CLASS_ID_OF(BodyText)}.  ); 


DEFINE(CommonContentGFS,  " 
<construction-expr>     ::=  <construction-factor> 

I  SEQ(<construction-factor>...); 

<construction-factor>    ::=  OBJECT_CLASS_ID_OF(CommonText) 

i  OBJECT_CLASS_ID_OF(PageNumber) 
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I  OBJECT_CLASS_ID_OF(CommonRaster) 
I  OBJECT_CLASS_ID_OF(CommonGeometric) 
I  OBJECT_CLASS_ID_OF(CommonReference) 
I  OBJECT_CLASS_ID_OF(CommonNumber) 
I  OBJECT_CLASS_ID_OF(Currentlnstance) 
I  OBJECT_CLASS_ID_OF(TableNumber); 

■) 


DEFINE(TableGFS." 

<construction-expr>  ::=  REP  CHO(OBJECT_CLASSJD_OF(Row).  .) 

I  REP  OBJECT_CLASS_ID_OF(Row) 
I  SEQ(OBJECT_CLASSJD_OF(Row)...); 

") 


DEFINE(RowGFS." 
<construction-expr>  ::= 
<simple-table> 


<complex-table> 
") 


DEFINE(TableComponentGFS," 

<construction-expr>  ::=  REP  OBJECT_CLASS_ID_OF(RowComponent); 

") 


<simple-table>  |  <complex-table>; 
REP  OBJECT_CLASS_ID_OF(EntryElement) 
I  REP  CHO(OBJECT_CLASS_ID_OF(EntryElennent)...) 
I  SEQ(OBJECT_CLASSJD_OF(EntryElement)...); 
SEQ(OBJECT_CLASS_ID_OF(EntryElement) 
OBJECT_CLASS_ID_OF(TableComponent)); 


DEFINE(RowComponentGFS,' 
<construction-expr>  ::= 


") 


REP  OBJECT_CLASS_ID_OF(EntryElement) 

|REP  CHO(OBJECT_CLASS_ID_OF(EntryElement)...) 

|SEQ(OBJECT_CLASSJD_OF(EntryElement)...); 


DEFINE(FormGFS," 
<construction-expr> 
<factor> 


AGG(<factor>...); 

OBJECT_CLASS_ID_OF(EntryElement) 
|OBJECT_CLASSJD_OF(EntryGroup); 


DEFINE(EntryGroupGFS,"$FormGFS" 


DEFINE(EntryElementGFS, 
<construction-expr>  :;= 


OBJECT_CLASS_ID_OF(EntryText) 

10BJECT_CLASS_ID_0F(EntryRaster) 

|OBJECT_CLASSJD_OF(EntryGeometric); 
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DEFINE(NumberedListGFS." 

<construction-expr>  ::=  SEQ(OBJECT_CLASSJD_OF(Number) 

OBJECT_CLASS_ID_OF(Listltem)) 
I  REP  SEQ(OBJECT_CLASS_ID_OF(Number) 
OBJECT_CLASS_ID_OF(L!Stltem)); 


DEFINE(UnNumberedListGFS." 

<construction-expr>  ::=  OBJECT_CLASS_ID_OF(Listltem) 

I  REP  OBJECT_CLASS_ID_OF(Listltem) 

I  SEQ(<separator-obj>  OBJECT_CLASS_ID_OF(Listltem)) 

I  REP  SEQ(<separator-obj>  OBJECT_CLASS_ID_OF(Listltem)); 

<separator-obj>  ::=  OBJECT_CLASS_ID_OF(BodyText) 

|OBJECT_CLASSJD_OF(BodyRaster) 
|OBJ  ECT_CLASS_I  D_OF(BodyGeometric) ; 


DEFINE(DefinitionListGFS." 

<construction-expr>    ;:=  SEQ(OBJECT_CLASS_ID_OF(ListTerm) 
OBJECT_CLASS_ID_OF(Listltem)) 
|REP  SEQ(OBJECT_CLASSJD_OF(ListTerm) 
OBJECT_CLASS_ID_OF(Ustltem)); 

") 


DEFINE{ListltemGFS." 

<construction-expr>     ::=  <term>  |  CHO{<term>...)  ; 

<term>  ::=  REP  OBJECT_CLASS_ID_OF(Phrase) 

I  OBJECT_CLASS_ID_OF(NumberedList) 
I  OBJECT_CLASSJD_OF(UnNumberedList) 
I  OBJECT_CLASS_ID_OF(DefinltionList); 

") 

DEFINE(ListTermGFS."$C0NSTRAINT-3") 
7.3.2  Factor  constraints 


7.3.2.1  FACTOR  ANY-LOGICAL 


{ 

GENERIC: 

REQ    Object-type  {VIRTUAL}, 

REG  Object-class-identifier  {ANY_VALUE} 
SPECIFIC: 

PERM   Object-type  {VIRTUAL}. 

REQ    Object-identifier  {ANY_VALUE}. 

REQ    Object -class  {VIRTUAL} 
SPECIFIC  AND  GENERIC: 
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PERM  Protection  {ANY_VALUE}, 

PERM  User-readable-comments  {ANY_STRING}. 

PERM  User-visible-name  {ANY_STRING} 

J 


7.3.2.2  FACTOR  COMP-LOGICAL 


:ANY-LOGICAL  { 
GENERIC: 

REQ  Object-type 
SPECIFIC: 

REQ  Subordinates 

PERM  Object-type 
SPECIFIC_AND_GENERIC: 

PERM  Bindings 

PERM  Defautt-value-lists 


{'composite-logical-object'} 
{VIRTUAL}. 

{'composite-logical-object'} 

{PMUL  {$SPECIFYBINDINGS}}, 

{REQ  #basic-logical-attributes 

{PERM  #presentation-style  {ANY_VALUE}, 
PERM  #layout-style  {ANY_VALUE}}} 


7.3.2.3  FACTOR  BASIC-LOGICAL 

:ANY-LOGICAL  { 
GENERIC: 

REQ  Object-type 

PERM  Resource 
SPECIFIC: 

PERM  Object-type 
SPECIFIC.  AND_GENERIC: 

PERM  Bindings 


{'basic-logicai-object'}, 
{ANY_VALUE} 

{'basic-logical-object'} 

{PMUL  {$SPECIFYBINDINGS}} 


7.3.2.4  FACTOR  ANY-COMMON 


GENERIC: 

REQ  Object-type  {VIRTUAL}, 

REQ  Object-class-identifier  {ANY_VALUE}, 

PERM  Bindings  {PMUL  {$SPECIFYBINDINGS}}. 

PERM  Protection  {ANY_VALUE}. 

PERM  User-readable-comments  {ANY_STRING}. 

PERM  User-visible-name  {ANY_STRING} 
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7.3.3  Constituent  constraints 


7.3.3.1  DocumentLogicalRoot 


:ANY-LOGICAL  { 

GENERIC: 

REQ  Object-type 

REQ  Generator-tor-subordinates 

REQ  Application-comments 

SPECIFIC: 

PERM  Object-type 
REQ  Object-class 
REQ  Subordinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Bindings 

PERM  Default-value-lists 


('document-logical-root'}, 

{SDocLogRootGFS}. 

{REQ  #constraint-name  {"0"}, 

PERM  #external-data  {ANY_VALUE}} 

{'document-logical-root'}, 

{OBJECT_CLASS_ID_OF(DocumentLogicalRoot)}, 
{SUBJD_OF(NumberedSegment)-^, 

SUBJD_OF(Passage)+}, 
{REQ  #constraint-name  {"0"}. 

PERM  #external-data  {ANY_ VALUE}} 

{PMUL  {SSPECIFYBINDINGS}, 
PERM  {$INITIALISEFNOTE}}, 
{REQ  #basic-logical-attributes 

{PERM  #presentation-style  {ANY_VALUE}, 
PERM  #layout-style  {ANY_VALUE}}} 


7.3.3.2  Passage 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Bindings 


{$PassageGFS}, 
{REQ  #constraint-name  {"1"}, 
PERM  #external-data  {ANY_ VALUE}} 

{OBJECT_CLASS_ID_OF(Passage)}. 
{SUBJD_OF(Title), 

SUB_ID_OF(Passage)-i-, 

SUB_ID_OF(NumberedSegment)-t-, 

SUB_ID_OF(BodyText)+, 

SUB_ID_OF(BodyRaster)+, 

SUB_ID_OF(BodyGeometric)-H. 

SUB_ID_OF(Figure)-^, 

SUBJD_OF(Paragraph)+, 

SUBJD_OF(Table)+, 

SUBJD_OF(NumberedList)-t-, 

SUB_ID_OF(DefinitionList)-i-, 

SUBJD_OF(UnNumberedList)-h}, 
{REQ  #constraint-name  {"1"}, 

PERM  #extemal-data   {ANY_ VALUE}} 

{PMUL  {$SPECIFYBINDINGS}, 
PERM  {$INITIALISEFNOTE}}, 
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PERM  Layout-Style 


{STYLEJD_0F(LStyle1)} 


7.3.3.3  NumberedSegment 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{SNumberedSegmentGFS}, 
{REQ  #constraint-name  {"2"}. 
PERM  #extemal-data  (ANY_VALUE}} 

{OBJECT_CLASS_ID_OF{NumberedSegment)}, 
{SUBJD_OF(Number), 
SUB_ID_OF(Title), 
SUB_ID_OF(Passage)+. 
SUB_ID_OF(NumberedSegment)-i-, 
SUBJD_OF(BodyText)-h, 
SUB_ID_OF(BodyRaster)-(-, 
SUB_ID_OF(BodyGeometric)-i-. 
SUBJD_OF(Paragraph)+, 
SUBJD_OF(Figure)-t-, 
SUB_ID_OF(Table)+, 
SUB_ID_OF(NumberedList)+, 
SUB_ID_OF(DefinitionList)+, 
SUB_ID_OF(UnNumberedList)+}, 
{REQ  #constraint-name  {"2"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.4  Number 

:BASIC-LOGICAL  { 

GENERIC: 

REQ  Content-generator 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
PERM  Content-generator 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 

} 


{$SEGMENTNUMBER}, 
{REQ  #constraint-name  {"3"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Number)}, 
{$SEGMENTNUMBER}. 
{REQ  #constraint-name  {"3"}, 
PERM  #external-data  {ANY_VALUE}} 

{STYLEJ  D_0F(LStyle2)} , 
{STYLEJD_0F{PStyle1)}. 
{$FC|$PC|$FPC} 
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7.3.3.5  Titte 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
Subordinates 


PERM  Application-comments 


SPECIFIC_AND_GENE 

PERM  Layout-style 


{$TitleGFS). 

{REQ  #constraint-name  {"4"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Title)}. 
{SUBJD_OF(BodyText)-h. 

SUB_ID_OF(BodyRaster)-^, 

SUBJD_OF(BodyGeometric)-^. 

SUBJD_OF(Phrase)+. 

SUBJD_OF{Footnote)+, 

SUB_ID_OF(Reference)+}, 
{REQ  #constraint-name  {"4"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.6  Caption 

:COMP-LOGICAL  { 
GENERIC: 

REQ  Generator-for-subordinates 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{SCaptionGFS}. 
{REQ  #constraint-name  {"5"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Caption)}, 
{SUBJD_OF(BodyText)-h, 

SUBJD_OF(Phrase)+, 

SUBJD_OF(Footnote)+, 

SUBJD_OF(Reference)+}. 
{REQ  #constraint-name  {"5"}. 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.7  Paragraph 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 


{$ParagraphGFS}, 
{REQ  #constraint-name  {"6"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASSJD_OF(Paragrapfi)}, 
{SUB_ID_OF(BodyText)-K. 
SUBJD_OF(Footnote)+, 
SUB_ID_OF(BodyRaster)-(-. 
SUBJD_OF(BodyGeometric)-h. 
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PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 


SUBJD_OF(Phrase)+, 
SUBJD_OF(Reference)+}, 
{REQ  #constraint-name  {"6"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle1)} 


7.3.3.8  Phrase 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Layout-style 

} 


{$PhraseGFS}, 
{REQ  #constraint-name  {"7"}, 
PERM  #extemal-data  {ANY_ VALUE}} 

{OBJECT_CLASS_ID_OF(Phrase)}. 
{SUB_ID_OF(BodyText)+, 
SUBJD_OF(Footnote)+, 
SUBJD_OF(Phrase)+, 
SUB_ID_OF(Reference)+}, 
{REQ  #constraint-name  {"7"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.9  Footnote 


:COMP-LOGICAL  { 
GENERIC: 

REQ  Generator-for-subordinates 

PERM  Bindings 


REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 

PERM  Bindings 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Layout-style 

} 


{$FootnoteGFS}, 

{PMUL  {$SPECIFYBINDINGS}. 

PERM{REQ{$INCFNOTENUMBER,$FNOTENUMBERSTRING} 

I  SFNOTESTRINGLITERAL}  }. 
{REQ  #constraint-name  {"8"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Footnote)}. 
{SUB_ID_OF(FootnoteReference), 

SUB_ID_OF(FootnoteBody)}, 
{PMUL  {SSPECIFYBINDINGS}. 

PERM  {$FNOTESTRINGLITERAL}}, 
{REQ  #constraint-name  {"8"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 
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7.3.3.10  FootnoteNumber 

:BASiC-LOGICAL  { 

GENERIC: 

REQ  Content-generator 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
PERM  Content-generator 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 


{$FNNUMBER}, 
{REQ  #constraint-name  {"9"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(FootnoteNumber)}. 
{$FNNUMBER}, 
{REQ  #constraint-name  {"9"}, 
PERM  #extemal-data  {ANY_ VALUE}} 

{STYLE_ID_0F(LStyie9)}, 
{STYLEJD_0F(PStyle1)}, 
{$FC|$PC|$FPC) 


7.3.3.11  FootnoteReference 


:BAS1C-L0GICAL  { 

GENERIC: 

REQ  Content-generator 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
PERM  Content-generator 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 

} 


{$FNNUMBER}, 
{REQ  #constraint-name  {"10"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(FootnoteReference)}. 
{SFNNUMBER), 
{REQ  #constraint-name  {"10"}, 
PERM  #external-data  {ANY  VALUE}} 

{STYLE  JD_OF(LStyle10)}, 

{STYLEJD_0F(PStyle1)}. 

{$FC|$PC|$FPC} 


7.3.3.12  FootnoteBody 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{$FootnoteBodyGFS}, 
{REQ  #constraint-name  {"11"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(FootnoteBody)}, 
{SUBJD_OF(FootnoteNumber), 

SUBJD_OF(FootnoteText)-H, 

SUBJD_OF(Reference)-t-}, 
{REQ  #constraint-name  {"11"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJDlOF(LStylell)} 
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7.3.3.13  FootnoteText 


:BASIC-L0GICAL  { 
GENERIC: 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 

PERM  Content-portions 


{REQ  #constraint-name  {"12"}, 
PERM  #external-data  {ANY_ VALUE}} 

{OBJECT_CLASS_ID_OF(FootnoteText)}. 
{REQ  #constraint-name  {"12"}, 
PERM  #external-data  {ANY_ VALUE}} 

{STYLEJD_0F(LStyle6)}, 
{STYLEJD  OF(PStylel)}, 
{$FC|$PC|$FPC}, 

{CONTENT_ID_OF(Character-content-portion)+} 


7.3.3.14  Figure 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{$FigureGFS}, 

{REQ  #constraint-name  {"13"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Figure)}, 
{SUB_ID_OF(Number), 

SUBJD_OF{Caption), 

SUBJD_OF(Description), 

SUBJD_OF(Artwork). 

SUB_ID_OF(Form)}, 
{REQ  #constraint-name  {"13"}, 

PERM  #external-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.15  BodyText 

:BASIC-LOGICAL  { 
GENERIC: 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 


{REQ  #constraint-name  {"14"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(BodyText)}, 
{REQ  #constraint-name  {"14"}, 
PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle2)}, 
{STYLE  JD_0F{PStyle1)}. 
{$FC|$PC|$FPC}, 
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PERM   Content-portions  {CONTENT_ID_OF(Character-content-portion)+} 

The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
otherwise  the  attribute  "resource"  must  be  specified.  -- 

} 


7.3.3.16  Reference 


;COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-Style 

} 


{$ReferenceGFS}. 
{REQ  #constraint-name  {"15"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Reference)}, 
{SUBJD_OF(BodyText)+. 

SUB_ID_OF(ReferencedContent)}, 
{REQ  #constraint-name  {"15"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle1)} 


7.3.3.17  ReferencedContent 


:BASIC-LOGICAL  { 
GENERIC: 


REQ 

Application-comments 

{REQ  #constraint-name  {"16"}. 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC 

REQ 

Object -class 

{OBJECT  CLASS  ID  OF(ReferencedContent)}, 

PERM 

Content -generator 

{$REF}, 

PERM 

Content-portions 

{CONTENTJD_OF(Character-content-portion)+}, 

-  Either  Content-generator  or  Content-portions  is  specified 

PERM 

Application-comments 

{REQ  #constraint-name  {"16"}, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC 

_AND_GENERIC: 

PERM 

Layout-style 

{STYLE  ID_OF(LStyle10)}, 

PERM 

Presentation-style 

{STYLE  ID  OF(PStylel)}, 

PERM 

Content-architecture-class 

{$FC|$PC|$FPC} 

} 


7.3.3.18  BodyRaster 

:BASIC-LOGICAL  { 

GENERIC: 

REQ  Content-architecture-class 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Content-architecture-class 

PERM  Application-comments 


{$FPR}. 

{REQ  #constraint-name  {"17"}, 
PERM  #extemal-data  { AN Y_ VALUE}} 

{OBJECT_CLASSJD_OF(BodyRaster)}, 
{$FPR}, 

{REQ  #constraint-name  {"17"}, 
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PERM  #external-data  {ANY_VALUE}} 

SPECIFIC_AND_GENERIC : 

PERM  Layout-style  {STYLE_ID_0F(LStyle5)}, 
PERM   Presentation-style  {STYLE_ID_0F(PStyle3)}, 

PERM   Content-portions  {CONTENT_ID_OF(Raster-graphics-content-portion)} 
-  The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
otherwise  the  attribute  "resource"  must  be  specified.  ~ 


7.3.3.19  BodyGeometric 


iBASIC-LOGICAL  { 


GENERIC 

REQ 

Content-architecture-class 

{$FPG}, 

REQ 

Application-comments 

{REQ  #constraint-name  {"18"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC 

REQ 

Object-class 

{OBJECT  CLASS  ID  OF(BodyGeometric)}. 

PERM 

Content-architecture-class 

{$FPG}, 

PERM 

Application-comments 

{REQ  #constraint-name  {"18"}, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC 

_AND_GENERIC: 

PERM 

Layout-style 

{STYLE  ID  0F(LStyle5)}, 

PERM 

Presentation-style 

{STYLEJD_0F(PStyle2)}, 

PERM 

Content-portions 

{CONTENT_ID_OF(Geometric-graphics-content-portion)} 

-  The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
otherwise  the  attribute  "resource"  must  be  specified.  - 

} 


7.3.3.20  CommonContent 

:ANY-COMMON  { 

GENERIC: 

REQ  Object-type 

REQ  Generator-for-subordinates 

REQ  Application-comments 

PERM  Default-value-lists 


} 


7.3.3.21  CommonText 

:ANY-COMMON  { 


GENERIC 

REQ 

Object-type 

{'basic-logical-object'}, 

PERM 

Content-portions 

{CONTENT_ID_OF(Character-content-portion)+}, 

PERM 

Resource 

{ANY  VALUE}, 

PERM 

Layout-style 

{STYLE  ID  0F(LStyle3)}. 

PERM 

Presentation-style 

{STYLE_ID_0F(PStyle4)}. 

PERM 

Content-architecture-class 

{$FC|$PC|$FPC}, 

REQ 

Application-comments 

{REQ  #constraint-name  {"20"}, 

PERM  #external-data  {ANY_VALUE}} 

{'composite-logical-object'}, 
{SCommonContentGFS}, 
{REQ  #constraint-name  {"19"}. 
PERM  #external-data  {ANY_VALUE}}, 
{REQ  #basic-logical-attributes 

{PERM  #presentation-style  {ANY_VALUE}, 
PERM  #layout-style  {ANY_VALUE}}} 
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} 


--  Either  the  attribute  "content  portions"  or  "resource"  must  be  specified  in  the  above  constituent 
constraint.  -- 


7.3.3.22  CommonReference 

:ANY-COMMON  { 

GENERIC: 

REQ  Object-type 
PERM  Content-generator 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 


{'basic-logical-object'}, 
{$COMMONREF}. 
{SPr'LE_ID_0F(LStyle3)). 
{STYLE_ID_0F(PStyle4)}, 
{$FC|$PC|$FPC), 
{REQ  #constraint-name  {"37"}, 
PERM  #extemal-data  {ANY_VALUE}} 


7.3.3.23  CommonNumber 

:ANY-COMMON  { 

GENERIC 

REQ    Object -type 
PERM  Content-generator 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 


{'basic-logical-object'}. 
{SCOMMONNUMBER}, 
{STYLE_ID_0F(LStyle3)}. 
{STYLEJD_0F(PStyle4)}, 
{$FC|$PC|$FPC}. 
{REQ  #constraint-name  {"38"}. 
PERM  #external-data  {ANY_ VALUE}} 


7.3.3.24  Currentlnstance 

;ANY-COMMON  { 

GENERIC: 

REQ  Object-type 
PERM  Content-generator 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 


{'basic-logical-object'}, 
{$CURRENTINSTANCE}, 
{STYLEJD_0F(LStyle3)), 
{STYLE_ID_0F{PStyle4)}, 
{$FC|$PC|$FPC}, 
{REQ  #constraint-name  ("39"}, 
PERM  #external-data  {ANY_VALUE}} 


7.3.3.25  CommonRaster 

:ANY-COMMON  { 
GENERIC: 

REQ    Object-type  {'basic-logical-object'}, 

PERM   Content-portions  {CONTENTJD_OF(Raster-graphics-content-portion)}. 

PERM    Resource  {ANY_VALUE}. 

PERM    Layout-style  {STYLEJD_0F(LStyle8)}, 
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PERM   Presentation-style  {STYLEJD_0F(PStyle3)}, 

REQ    Content-architecture-class  {$FPR}, 

REQ    Application-comments         {REQ  #constraint-name  {"21"}, 

PERM  #external-clata  {ANY_VALUE}} 

-  Eittier  the  attribute  "content  portions"  or  "resource"  must  be  specitied  in  the  above  constituent 

constraint.  - 


7.3.3.26  CommonGeometric 


:ANY-COMMON  { 


GENERIC 

REQ 

Object-type 

{'basic-logical-object'}, 

PERM 

Content -portions 

{CONTENT  ID  OF(Geometric-graphics-content-portion)}, 

PERM 

Resource 

{ANY  VALUE}, 

PERM 

Layout-style 

{STYLE  ID  0F(LStyle8)), 

PERM 

Presentation-style 

{STYLEJD_0F(PStyle2)}, 

REQ 

Content-architecture-class 

{$FPG}, 

REQ 

Application-comments 

{REQ  #constraint-name  {"22"}, 

PERM  #extemal-data  {ANY_VALUE}} 

-  Either  the  attribute  "content  portions"  or  "resource"  must  be  specified  in  the  atx)ve  constituent 
constraint.  - 

} 


7.3.3.27  PageNumber 

:ANY-COMMON  { 

GENERIC: 

REQ  Object-type 
PERM  Content-generator 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 


{'basic-logical-object}, 
{$PGNUMBER}, 
{STYLEJD_0F(LStyle3)}, 
{STYLEJD_0F{PStyle4)}, 
{$FC|$PC|$FPC}, 
{REQ  #constraint-name  {"40"}, 
PERM  #external-data  {ANY_VALUE}} 


7.3.3.28  TableNumber 

:ANY-C0MM0N  { 

GENERIC: 

REQ  Object-type 
PERM  Content-generator 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
REQ  Application-comments 

} 


{'basic-logical-object'}, 
{$TABLENUMBER}, 
{STYLEJD_0F(LStyle3)}, 
{STYLEJD_0F(PStyle4)}, 
{$FC|$PC|$FPC}. 
{REQ  #constraint-name  {"44"}, 
PERM  #extemal-data  {ANY_VALUE}} 
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7.3.3.29  Description 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC.  AND_GENERIC: 
PERM  Layout-style 


{$DescriptionGFS}. 
{REQ  #constraint-name  {"23"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Description)}. 
{SUBJD_OF(BodyText)-H. 

SUB_I  D_OF(Footnote)+. 

SUBJD_OF(Phrase)-^. 

SUB_ID_OF(Reference)-^}. 
{REQ  #constraint-name  {"23"}. 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.30  Artwork 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layoul-style 

} 


{$ArtworkGFS}. 
{REQ  #constraint-name  {"24"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Artwork)}. 
{SUBJD_OF(BodyRaster)+, 

SUB_ID_OF(BodyGeometric)-^. 

SUB_ID_OF(  Phrase  )-k}. 
{REQ  #constraint-name  {"24"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle12)} 


7.3.3.31  NumberedList 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{$NumberedListGFS}, 
{REQ  #constraint-name  {"25"}. 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(NumberedList)}. 
{SUBJD_OF(Number)-j-, 

SUBJD_OF(Listltem)+  }. 
{REQ  #constraint-name  {"25"}. 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLE_ID_0F(LStyle1)} 
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7.3.3.32  UnNumberedList 


{SUnNumberedListGFS}, 
{REQ  #constraint-name  {"26"}, 
PERM  #external-data  {ANY_VALUE}} 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{OBJECT_CLASSJD_OF(UnNumberedList)}. 
{SUB_ID_OF(BodyText)+, 
SUB_ID_OF(BodyRaster)+. 
SUB_ID_OF(BodyGeometric)+, 
SUB_ID_OF(Listltem)-t-  }, 
{REQ  #constraint-name  {"26"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{STYLEJD_0F(LStyle1)} 


7.3.3.33  DefinitionList 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


7.3.3.34  Listltem 


{$DefinitionUstGFS}, 
{REQ  #constraint-name  {"27"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASSJD_OF(DefinitionList)}. 
{SUB_ID_OF(ListTermH, 

SUB_ID_OF(ListltemK  }. 
{REQ  #constraint-name  {"27"}. 

PERM  #external-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 
SPECIFIC_AND_GENERIC: 


{$ListltemGFS}. 
{REQ  #constraint-name  {"28"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(Listltem)}, 

{SUBJD_OF(Ptirase)+, 
SUBJD_OF(NumberedList)+, 
SUBJD_OF(UnNumberedList)+, 
SUBJD_OF(DefinitionList)-K }. 

{REQ  #constraint-name  {"28"}, 
PERM  #external-data  {ANY_VALUE}} 
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PERM  Layout-style 

} 


{STYLE_ID_0F(LStyle1)) 


7.3.3.35  ListTerm 


;COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Layout-style 

} 


{$ListTermGFS}, 
{REQ  #constraint-name  {"29"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(ListTerm)}, 
{SUB_ID_OF(BodyText)-h, 

SUB_ID_OF(BodyRaster)+, 

SUB_ID_OF(BodyGeometric)-(-, 

SUB_ID_OF{Reference)+, 

SUBJD_OF(Phrase)+. 

SUB_ID_OF{Footnote)H-  }. 
{REQ  #constraint-name  {"29"}, 

PERM  #extemal-data  {ANY_VALUE}} 

{STYLEJD_0F(LStyle1)} 


7.3.3.36  Table 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-tor-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Application-comments 

PERM  Layout-style 

} 


{$TableGFS}, 

{REQ  #constraint-name  {"30"}, 
PERM  #external-data  {ANY_VALUE}}. 
{STYLEJD_0F(LStyleT4)} 

{OBJECT_CLASS_ID_OF(Table)}. 
{SUBJD_OF(Row)-^}, 
{REQ  #constraint-name  {"30"}. 
PERM  #extemal-data  {ANY_VALUE}}, 
{STYLEJD_0F(LStyleT8)} 


7.3.3.37  Row 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


{SRowGFS}, 

{REQ  #constraint-name  {"31"}, 
PERM  #external-data  {ANY_VALUE}}. 
{STYLE_ID_0F(LStyleT5)} 

{OBJECT_CLASSJD_OF(Row)}, 
{SUB_ID_OF(EntryElement)+, 
SUBJD_OF(TableComponent)}, 
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PERM  Application-comments 

} 


{REQ  #constraint-name  {"31"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{$TableComponentGFS}, 
{REQ  #constraint-name  {"32"}, 
PERM  #extemal-data  {ANY_VALUE}}, 
{STYLEJD_0F(LStyleT6)} 


7.3.3.38  TableComponent 

:COMP-LOGICAL  { 

GENERIC; 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Application-comments 


{OBJECT_CLASS_ID_OF(TableComponent)}, 
{SUB_ID_OF(RowComponent)-f}, 
{REQ  #constraint-name  {"32"}, 
PERM  #extemal-data  {ANY_VALUE}} 


7.3.3.39  RowComponent 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 

REQ  Subordinates 

PERM  Application-comments 


{$RowComponentGFS}, 
{REQ  #constraint-name  {"33"}, 
PERM  #external-data  {ANY_VALUE}}. 
{STYLEJD_OF(LStyleT7)} 

{OBJECT_CLASSJD_OF(RowComponent)}. 
{SUBJD_OF(Entry  Element)-!-}. 
{REQ  #constraint-name  {"33"}. 
PERM  #external-data  {ANY_VALUE}} 


7.3.3.40  Form 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 

PERM  Application-comments 


{$FormGFS}, 

{REQ  #constraint-name  {"34"}, 
PERM  #external-data  {ANY_VALUE}}, 
{STYLEJD_0F(LStyleT1 )} 

{OBJECT_CLASSJD_OF(Form)}, 
{SUB_ID_OF(EntryElement)-h, 

SUBJD_OF(EntryGroup)-K}, 
{REQ  #constraint-name  {"34"}. 

PERM  #external-data  {ANY_VALUE}} 
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7.3.3.41  EntryElement 


:C0MP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

REQ  Layout-style 
SPECIFIC: 

REQ  Object-class 
REQ  Subordinates 


PERM  Application-comments 


{SEntryElementGFS}. 
{REG  #constraint-name  {"35"}, 
PERM  #extemal-data  {ANY_VALUE}}. 
{STYLE_I  D_0F(LStyleT2)} 

{OBJECT_CLASSJD_OF(EntryElement)}. 
{SUB_ID_OF(EntfyText). 

SUB_ID_OF(EntryRaster). 

SUBJD_OF(EntryGeometric)}. 
{REQ  #constraint-name  {"35"). 

PERM  #extemal-data  {ANY_VALUE}} 


7.3.3.42  EntryGroup 

:COMP-LOGICAL  { 

GENERIC: 

REQ  Generator-for-subordinates 
REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 
REQ  Sutx)rdinates 

PERM  Application-comments 

SPECIFIC,  AND_GENERIC: 
PERM  Layout-style 


{$EntryGroupGFS}. 
{REQ  #constraint-name  {"36"}, 
PERM  #external-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(EntryGroup)}. 
{SUBJD_OF(EntryElement)+, 

SUBJD_OF(EntryGroup)+}, 
{REQ  #constraint-name  {"36"}, 

PERM  #extemal-data   {ANY_ VALUE}} 

{STYLE_ID_0F(LStyleT3)} 


7.3.3.43  EntryText 


:BASIC-LOGICAL  { 
GENERIC: 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-class 

PERM  Application-comments 


SPECIFIC.  AND_GENERIC: 
PERM  Layout-style 
PERM  Presentation-style 
PERM  Content-architecture-class 
PERM  Content-portions 


{REQ  #constraint-name  {"41"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{OBJECT_CLASS_ID_OF(EntryText)}. 
{REQ  #constraint-name  {"41"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{STYLE_ID_0F(LStyleT9)}. 
{STYLE_ID_0F(PStyle1)}. 
{$FC|$PC|$FPC}. 

{CONTENT_ID_OF(Character-content-portion)+} 
"  The  attribute  "content  portions"  rrwst  be  specified  either  in  the  specific  or  generic  part, 
othenvise  the  attribute  "resource"  must  be  specified.  - 


164 


7.3.3.44  EntryRaster 

:BASIC-LOGICAL  { 


GENERIC 

REQ 

Content-architecture-class  . 

{$FPR}, 

REQ 

Application-comments 

{REQ  #constraint-name  {"42"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC 

REQ 

Object-class 

{OBJECT_CLASS_ID_OF(EntryRaster)}, 

PERM 

Content-architecture-class 

{$FPR}, 

PERM 

Application-comments 

{REQ  #constraint-name  {"42"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC 

_AND_GENERIC: 

PERM 

Layout-style 

{STYLE  ID  0F{LStyleT9)}, 

PERM 

Presentation-style 

{STYLE_ID_0F(PStyle3)}, 

PERM 

Content-portions 

{CONTENT_ID_OF(Raster-graphics -content-portion)} 

-  The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
othenft^ise  the  attribute  "resource"  must  be  specified.  ~ 

} 


7.3.3.45  EntryGeometric 


:BASIC-LOGICAL  { 


GENERIC 

REQ 

Content-architecture-class 

{$FPG}, 

REQ 

Application-comments 

{REQ  #constraint-name  {"43"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC 

REQ 

Object-class 

{OBJECT  CLASS  ID  OF(EntryGeometric)}, 

PERM 

Content-architecture-class 

{$FPG}, 

PERM 

Application-comments 

{REQ  #constraint-name  {"43"}, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC 

_AND_GENERIC: 

PERM 

Layout-style 

{STYLE_I  D_OF(LSty  leT9) } , 

PERM 

Presentation-style 

{STYLE_ID_0F(PStyle2)}, 

PERM 

Content-portions 

{CONTENT_ID_OF(Geometric-graphics-content-portion)} 

-  The  attribute  "content  portions"  must  be  specified  either  in  the  specific  or  generic  part, 
otherwise  the  attribute  "resource"  must  be  specified.  - 

} 


7.4  Layout  constituent  constraints 

7.4.1  Macro  definitions 

DEFINE(DocLayRootGFS,  " 

<construction-expr>     ::=  <construction-term>|<construction-type>; 

<construction-term>     ::=  <construction-factor> 

I  OPT  <construction-factor> 
I  REP  <construction-factor> 
I  OPT  REP  <construction-factor>; 

<construction-type>     ::=  SEQ(<constmction-term>...) 
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I  CHO(<construction-term>...); 


<construction-1ac(or>    ::=  OBJECT_CLASSJD_OF(PageSet) 

j  <construction-type>; 


DEFINE(PageSetGFS. 
<construction-expr> 


::=  <construction-term>|<construction-type>; 


<construction-term> 


=  <construction-factor> 
I  OPT  <construction-factor> 
I  REP  <construction-factor> 
OPT  REP  <construction-factor>; 


<construction-type> 


<construction-!actor> 


=  SEQ(<construction-term>...) 
I  CHO(<construction-term>.  .); 

=  OBJECT_CLASS_ID_OF(Page) 
I  OBJECT_CLASS_ID_OF(RectoPage) 
I  OBJECT_CLASS_ID_OF(VersoPage) 
I  <constnjction-type>; 


DEFINE(PageGFS. 
<construction-expr> 


<headerarea> 


<bodyarea> 


<footerarea> 


::=  SEQ((<headerarea>)<bodyarea>[<footerarea>]) 
I  SEQ(<bodyarea>(<headerarea>](<footerarea>]) 
I  SEQ((<headerarea>)I<footerarea>]<bodyarea>) 
I  <bodyarea>; 

:  :=  OBJECT_CLASS_ID_OF(BasicHeader) 
I  OBJECT_CLASS_ID_OF(CompositeHeader); 

::=  OBJECT_CLASS_ID_OF(VariableCompositeBody) 
I  OBJECT_CLASS_ID_OF(FixedCompositeBody) 
I  OBJECT_CLASS_ID_OF(BasicBody); 

:.=  OBJECT_CLASS_ID_OF(BasicFooter) 
I  OBJECT_CLASS_ID_OF(CompositeFooter); 


DEFINE(CompositeCommonGFS.  " 
<construction-expr>     ::=  <fixed-common-content-frames> 

I  <variable-common-content-f rames> , 

<fixed-common-content-trames> 

::=  SEQ({OBJECT_CLASSJD_OF(SourcedContentFixed) 
I  OBJECT_CLASS_ID_OF(ArrangedContentFixed)}  ..); 

<variable-common-content-frames> 

::=  SEQ{{OBJECT_CLASS_ID_OF(SourcedContentVariable) 
I  OBJECT_CLASS_l D_OF(ArrangedContentVariable)} . . .) ; 

") 
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DEFINE(HeaderFooterGFS.  "$CompositeCommonGFS") 


DEFINE(FixedCompositeBodyGFS,  " 
<construction-expr>     ::=  SEQ(<construction-term>...); 


<construction-term>     :;=  <constnjction-factor1  > 

I  OPT  <construction-factor1> 
I  CHO({<construction-factor1  >}...) 
I  <construction-factor2>; 


<construction-f  actor  1 : 


:=  OBJECT_CLASS_ID_OF(BasicFixture) 
I  OBJECT_CLASS_ID_OF(ColumnFixed) 
I  OBJECT_CLASSJD_OF(CompositeFixtureFixed) 
I  OBJECT_CLASSJD_OF(VariableCompositeBody); 


<construction-factor2>  ::=  OBJECT_CLASS_ID_OF(CompositeCommon) 

I  OBJECT_CLASS_ID_OF(SourcedContentFixed) 
I  OBJ ECT_CLASSJ D_OF( ArrangedContentFixed) : 

") 


DEFINE(VariableCompositeBodyGFS, 


<construction-expr> 


:=  <construction-term>|<construction-type> 
I  SEQ(<construction-term>,  <construction-footnote>) 
I  SEQ(<construction-type>.  <construction-footnote>); 


<construction-term> 


;  :=  <construction-factor1  > 
I  OPT  <construction-tactor1  > 
I  REP  <construction-factor1  > 
I  OPT  REP  <constnjction-factor1>; 


<construction-type>     ::=  SEQ({<construction-term>  |  <construction-factor2>}...) 

I  CHO({<construction-term>}...); 

<construction-factor1>  ::=  OBJECT_CLASS_ID_OF(BasicFloat) 

I  OBJECT_CLASS_ID_OF(SnakingColumns) 

I  OBJECT_CLASSJD_OF(SynchronizedColumns) 

I  OBJECT_CLASS_ID_OF(CompositeFloat) 

I  OBJECT_CLASS_ID_OF(CompositeFixtureVariable) 

I  OBJECT_CLASS_ID_OF(TableArea) 

I  OBJECT_CLASS_ID_OF(FootnoteArea) 

I  <construction-type>; 


<construction-footnote>  ::=  OBJECT_CLASS_ID_OF(FootnoteArea) 

I  OPT  OBJECT_CLASS_ID_OF(FootnoteArea); 

<construction-factor2>  : :=  OBJECT_CLASS_ID_OF(ArrangedContentVariable) 

I  OBJECT_CLASS_ID_OF(SourcedContentVariable); 


DEFINE(SnakingColumnsGFS,  " 
<construction-expr>     ;:=  REP  <construction-factor1  > 
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I  <construction-term> 

I  SEQ(<construction-type>...); 

<construction-term>     ::=  SEQ(<construction-type><following-term>); 

<following-term>         ::=  OPT<construction-factor1  > 

I  <construction-factor2> 
I  OPT<construction-term>  ; 


<construction-type>     ::=  <construction-factor1  >|<construction-factor2>; 
<construction-factor1>  ::=  OBJECT_CLASS_ID_OF(ColumnVariable) 

I  OBJECT_CLASS_ID_OF(CompositeColumnVariable); 
<construction-factor2>  ::=  OBJ ECT_CLASSJD_OF(ArrangeclContent Variable) 

I  OBJECT_CLASS_ID_OF(SourcedContentVariable); 

••) 


DEFINE(SynchronizeclColumnsGFS.  " 

<construction-expr>     :.=  SEQ({<constmction-type>}...)|<construction-term>; 


<construction-term>     ::=  SEQ(<construction-type><following-term>); 
<following-term>         ::=  OPT<construction-tactor1  > 

I  <constaiction-factor2> 

I  OPT<constmction-term>  ; 
<construction-type>     ::=  <construction-factor1  >|<construction-factor2>; 
<construction-f actor!  >  ::=  OBJECT_CLASS_ID_.OF(ColumnFixecl) 

I  OBJECT_CLASS_ID_OF(CompositeColumnFixed); 
<construction-factor2>  ::=  OBJECT_CLASS_ID_OF(ArrangeclContentFixed) 

I  OBJECT_CLASS_ID_OF(SourcedContentFixed); 

") 


DEFINE(CompositeFloatGFS,  " 

<construction-expr>     ;:=  SEQ(<constnjction-term1>  (<construction-term2>]...); 

<construction-term1  >    ;  :=  <construction-factor1  >|<construction-f  actor2> ; 
<construction-term2>    ::=  <construction-term1> 

I  OPT<construction-tactor1>; 
<construction-factor1>  ::=  OBJECT_CLASS_ID_OF(BasicColumn) 

I  OBJECT_CLASS_ID_OF(CompositeFixtureVariable) 

I  OBJECT_CLASSJD_OF(TableArea); 
<construction-factor2>  ;:=  OBJ ECT_CLASS_ID_OF(ArrangedContent Variable) 

I  OBJECT_CLASSJD_OF(SourcedContentVariable) ; 

") 


DEFINE(CompositeColumnGFS,  " 
<construction-expr>     ::=  <construction-term> 

I  <construction-type> 

I  SEQ(<construction-term>  <constnjction-footnote>) 
I  SEQ(<construction-type>  <construction-footnote>); 


<construction-term>     ::=  <construction-factor1> 

I  OPT  <constnjction-factor1> 
I  REP  <construction-factor1  > 
I  OPT  REP  <construction-factor1>; 
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<constructk)n-type>     ::=  SEQ({<construction-term>  |  <construction-factor2>}...) 

I  CHO({<construction-term>}...); 

<construction-factor1>  ::=  OBJECT_CLASS_ID_OF(BasicFloat) 

I  OBJECT_CLASS_ID_OF(TableArea) 
I  OBJECT_CLASS_ID_OF(CompositeFloat) 
j  OBJECT_CLASSJ D_OF(CompositeFixture Variable) 
I  OBJECT_CLASSJD_OF(FootnoteArea) 
I  <construction-type>; 

<construction-footnote>  ::=  OBJECT_CLASS_ID_OF(FootnoteArea) 

I  OPT  OBJECT_CLASS_ID_OF(FootnoteArea); 
<construction-factor2>  ::=  OBJ  ECT_CLASS_ID_OF(ArrangedContent Variable) 

I  OBJECT_CLASS_ID_OF(SourcedContentVariable); 

") 


DEFINE(CompositeColumnVariableGFS.  "$CompositeColumnGFS") 


DEFINE(CompositeColumnFixedGFS.  "$CompositeColumnGFS") 


DEFINE(CompositeFixtureGFS,  " 
<construction-expr>     ::=  <construction-factor> 

I  REP  CHO(<construction-factor>...); 

<construction-factor>    ::=  OBJECT_CLASS_ID_OF(BasicFloat) 

I  OBJECT_CLASS_ID_OF(FootnoteArea) 
I  OBJECT_CLASS_ID_OF(CompositeArtwork) 
I  OBJECT_CLASS_ID_OF(FormArea); 

") 


DEFINE(CompositeFixtureFixedGFS.  "$CompositeFixtureGFS") 


DEFINE(CompositeFixtureVariableGFS.  "$CompositeFixtureGFS") 


DEFINE(CompositeArtwofKGFS.  " 

<construction-expr>  ::=  REP  OBJECT_CLASSJD_OF(BasicFixture); 
") 


DEFINE(TableAreaGFS.  " 
<construction-expr>     ::=  <row-area> 

!  SEQ([<table-header>]  (<table-label>l  <row-area>[<table-label>l); 
<table-header>  ;:=  OBJECT_CLASS_ID_OF{TableHeader); 

<table-label>  ::=  OBJECT_CLASS_ID_OF(TableLabel). 

<row-area>  ::=  REP  OBJECT_CLASSJD_OF(RowArea) 

I  REP  CHO(OBJECT_CLASS_ID_OF(RowArea)...); 

") 

DEFINE(RowAreaGFS." 
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<construction-expr>     ::=  SEQ(OBJECT_CLASS_ID_OF(Cell)...) 

I  SEQ(OBJECT_CLASSJD_OF(Cell) 

OBJECT_CLASS_ID_OF(SubRowGroup)); 

") 


DEFINE(SubRowGroupGFS." 

<construction-expr>  ::=  REP  OBJECT_CLASS_ID_OF(SubRow); 
") 


DEFINE(SubRowGFS." 

<construction-expr>  ::=  SEQ(OBJECT_CLASS_ID_OF(Cell)...): 
") 


DEFINE(TableHeaderGFS." 

<construction-expr>  ::=  SEQ(OBJECT_CLASSJD_OF{SourcedContentFixed)...); 
") 


DEFINE(TableLabelGFS." 

<construction-expr>     :.=  SEQ(OBJECT_CLASS_ID_OF(TableLabelContent)...) 

I  SEQ(OBJECT_CLASSJD_OF(TableLabelContent) 
OBJECT_CLASS_ID_OF(CompositeTableLabel)); 

••) 

DEFINE(CompositeTableLabelGFS," 

<construction-expr>  ::=  SEQ(OBJECT_CLASS_ID_OF(LabelComponent)...); 
") 


DEFINE(LabelComponentGFS." 

<construction-expr>     ;:=  SEQ(OBJECT_CLASSJD_OF(TableLabelContent)...); 


DEFINE(FormAreaGFS." 
<construction-expr>     ::=  AGG(<factor>...); 

<factor>  ::=  OBJECT_CLASS_ID_OF(ArrangedContentFixed) 

I  OBJECT_CLASS_ID_OF(FormEntryArea) 
I  OBJECT_CLASS_ID_OF(EntryGroupArea) ; 

") 


DEFINE(EntryGroupAreaGFS,"$FormAreaGFS") 


7.4.2  Factor  constraints 


7.4.2.1  FACTOR  ANY-LAYOUT 

{ 

GENERIC: 
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REQ  Object-type 

REQ  Object-class-identifier 
SPECIFIC: 

PERM  Object-type 

REQ  Object-identifier 

CASE  $DAC  OF  { 

$FDA:  PERM  Object-class 
$FPDA:  REQ  Object-class 
}. 

REQ  Subordinates 
SPECIFIC_AND_GENERIC: 

PERM  User-readable-comments 
PERM  User-visible-name 

} 


{VIRTUAL}, 
{ANY_VALUE} 

{VIRTUAL}, 
{ANY_VALUE}. 

{VIRTUAL} 
{VIRTUAL} 

{VIRTUAL} 

{ANY_STRING}, 
{ANY_STRING} 


7.4.2.2  FACTOR  ANY-PAGE 

:ANY-LAYOUT  { 
GENERIC: 

REQ  Object-type  {'page'}, 


CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator 
PERM  Bindings 


} 

SPECIFIC: 
PERM 
REQ 


Object -type 
Subordinates 


SPECIFIC_AND_GENERIC: 
PERM  Dimensions 
PERM  Transparency 
PERM  Colour 
PERM  Page-position 

} 


for-subordinates  {$PageGFS}, 
{PMUL  {SSPECIFYBINDINGS}, 

PERM  {$INITIALISEPGNUMBER.$USEPGNUMBERS}} 


{'page'}, 

{SUB_ID_OF(BasicHeader), 

SUBJD_OF(CompositeHeader), 

SUBJD_OF(BasicBody), 

SUB_ID_OF(FixedCompositeBody), 

SUBJD_OF(VariableCompositeBody), 

SUB_ID_OF(BasicFooter), 

SUB_ID_OF(CompositeFooter)} 


{$PermissiblePageDimensions}, 
{ANY_VALUE}, 
{ANY  VALUE}, 
{ANY_VALUE} 


7.4.2.3  FACTOR  ANY-FRAME-FIXED 

lANY-LAYOUT  { 
GENERIC: 

REQ    Object-type  {'frame'} 
SPECIFIC: 

PERM   Object-type  {'frame'} 
SPECIFIC_AND_GENERIC: 

PERM   Position  {REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}, 
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PERM  Dimensions 


PERM  Transparency 
PERM  Colour 
PERM  Border 


REQ  #vertical-position 

{REQ  #horizontal-dimension 
{REQ  #fixed-dimension 
REQ  #vertical-dimension 
{REQ  #fixed-dimension 

{ANY_VALUE}. 

{ANY_VALUE}. 

{ANY_VALUE} 


{ANY_VALUE}}}. 

{ANY_VALUE}}. 

{ANY_VALUE}}}. 


7.4.2.4  FACTOR  ANY-FRAME-VARIABLE 


:ANY-LAYOUT  { 
GENERIC: 

REQ  Object-type 
SPECIFIC: 

PERM  Object-type 

CASE  $DAC  OF  { 
$FPDA: 

REQ  Position 


REQ  Dimensions 


} 

SPECIFIC.  AND_GENERIC: 
CASE  $DAC  OF  { 
$FDA: 

PERM  Position 


PERM  Dimensions 


). 

PERM  Transparency 

PERM  Colour 

PERM  Border 


{'frame'} 
{'frame'}. 


{REQ  #fixed-position 

{REQ  #fiorizontal-position 

REQ  #vertical -position 
{REQ  #hori2ontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}). 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}} 


{ANY_VALUE}. 
{ANY_VALUE}}}, 


{REQ  #fixed-position 

{REQ  #horizontal-posltion 
REQ  #vertical-position 
{REQ  #hori2ontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}} 

{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE} 


{ANY_VALUE}. 
{ANY_VALUE}}}. 
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7.4.3  Constituent  constraints 


7.4.3.1  DocumentLayoutRoot 

:ANY-LAYOUT  { 
GENERIC: 

REQ  Object-type  {'document-layout-root'}, 
CASE  $DAC  OF  { 
$PDA-FPDA:  . 

REQ  Generator-for-subordinates  {$DocLayRootGFS}, 
PERM  Bindings  {PMUL  {$SPECIFYBINDINGS}, 

PERM  {SINITIALISEPGNUMBER}} 

}. 

REQ    Application-comments         {REQ  #constraint-name  {"0"}, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC: 

PERM  Object-type  {'document-layout-root'}, 
CASE  $DAC  OF  { 
$FDA: 

PERM   Object-class  {OBJECT_CLASS_ID_OF 

( Docu  mentLayout  Root) } 

$FPDA: 

REQ    Object-class  {OBJECT_CLASS_ID_OF 

(DocumentLayoutRoot)} 

}. 

REQ    Subordinates  {SUB_ID_OF(PageSet)+}. 
PERM   Application-comments        {REQ  #constraint-name  {"0"}. 

PERM  #extemal-data  {ANY_VALUE}} 

} 


7.4.3.2  PageSet 


:ANY-LAYOUT  { 
GENERIC: 

REQ  Object-type 


{'page-set'}, 


CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates 


{$PageSetGFS}. 


PERM  Bindings 


REQ  Application-comments 

SPECIFIC: 

PERM  Object-type 
CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 


{PMUL  {SSPECIFYBINDINGS}, 
PERM  {$INITIALISEPGNUMBER}} 

{REQ  #constraint-narne  {"1"}, 
PERM  #external-data  {ANY_VALUE}} 

{'page-set'}, 

{OBJECT_CLASS_ID_OF(PageSet)} 
{OBJECT_CLASS_ID_OF(PageSet)} 
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}. 

REQ  Subordinates 


PERM  Application-comments 


{SUBJD_OF(Page)+, 
SUBJD_OF(RectoPage)+, 
SUBJD_OF(VersoPage)+}, 
{REQ  #constraint-name  {"1"}, 
PERM  #extemal-cJata  {ANY_VALUE}} 


7.4.3.3  Page 

:ANY-PAGE  { 
GENERIC: 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 
$FPDA: 

REQ  Object-class 

}. 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Medium-type 


} 


{REQ  #constraint-name  {"2"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(Page)} 

{OBJECT_CLASS_ID_OF(Page)} 

{REQ  #constraint-name  {"2"}. 
PERM  #extemal-data  {ANY_ VALUE}} 

{PERM  #nominal-page-size  {$NominalPageSizes}. 
PERM  #side-of-sheet  {ANY_VALUE}} 


7.4.3.4  RectoPage 

:ANY-PAGE  { 
GENERIC: 

REQ  Application-comments 

REQ  Medium-type 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 
$FPDA: 

REQ  Object-class 

}. 

PERM  Application-comments 
PERM  Medium-type 


{REQ  #constraint-name  {"3"}, 
PERM  #extemal-data  {ANY_VALUE}}, 
{PERM  #nominal-page-size  {$NominalPageSizes}. 
REQ  #side-of-sheet  {'rectoTunspecified'}} 


{OBJ  ECT_C  LASS_I  D_0  F(  Recto  Page ) } 
{OBJECT_CLASS_ID_OF(RectoPage)} 

{REQ  #constraint-name  {"3"}, 
PERM  #extemal-data  {ANY_VALUE}}. 

{PERM  #nominal-page-size  {$NominalPageSizes}, 
PERM  #side-of-sheet  {'rectoTunspecified'}} 


174 


4.3.5  VersoPage 

,NY-PAGE  { 
ENERIC; 

REQ  Application-comments 

REQ  Medium-type 

PECIFIC: 
CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 
$FPDA: 

REQ  Object-class 

}. 

PERM  Application-comments 
PERM  Medium-type 


{REQ  #constraint-name  {"4"}, 
PERM  #extemal-data  {ANY_VALUE}}, 

{PERM  #nominal-page-size  {$NominalPageSizes}. 
REQ  #side-of-sheet  {'verso'l'unspecified'}} 


{OBJECT_CLASS_ID_OF(VersoPage)} 
{OBJECT_CLASS_ID_OF(  VersoPage)} 

{REQ  #constraint-name  {"4"}, 
PERM  #extemal-data  {ANY_ VALUE}}, 

{PERM  #nominal-page-si2e  {$NominalPageSizes}, 
PERM  #side-of-sheet{'versoTunspecified'}} 


r.4.3.6  CompositeHeader 

jANY-FRAME-FIXED  { 
GENERIC: 
I    CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for 
PERM  Layout-patti 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 


PERM  Imaging-order 
PERM  Application-comments 


subordinates  {$HeaderFooterGFS}}. 
{'270-degrees'-  H/F  layouts  A1.B2  - 
ri80-degrees'  -  H/F  layout  B1  - 
I'O-degrees'  -  H/F  layout  A2  -}, 
{REQ  #constraint-name  {"5"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASSJD_OF(CompositeHeader)} 
{OBJECT_CLASS_ID_OF(CompositeHeader)} 

{SUB_ID_OF(SourcedContentFixed)+. 
SUB_ID_OF(ArrangedContentFixed)+, 
SUB_ID_OF(SourcedContentVariable)+, 
SUBJD_OF(ArrangedContentVariable)+}. 

{SUBJD_OF(SourcedContentFixed)-h. 
SUB_ID_OF(ArrangedContentFixed)-t-}. 

{REQ  #constraint-name  {"5"}, 
PERM  #external-data  {ANY_VALUE}} 


175 


7.4.3.7  CompositeFooter 


:ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for 
PERM  Layout-path 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Imaging-order 
PERM  Application-comments 


subordinates  {$HeaderFooterGFS}}. 
{'270-degrees'  -  H/F  layouts  A1.B2  - 
ri80-degrees*  -  H/F  layout  B1  - 
j'O-degrees'  -  H/F  layout  A2  -}. 
{REQ  #constraint-name  {"32"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(CompositeFooter)} 

{OBJECT_CLASS_ID_OF(CompositeFooter)} 

{SUBJD_OF(SourcedContentFixed)+. 
SUB_ID_OF(ArrangedContentFixed)+. 
SUB_ID_OF(SourcedContentVariable)+. 
SUBJD_OF(ArrangedContentVariable)+}, 
{SUB_ID_OF(SourcedContentFixed)+, 
SUB_ID_OF(ArrangedContentFixed)+}. 
{REQ  #constraint-name  {"32"}. 
PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.8  FisedCompositeBody 

;ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for 
PERM  Layout-patti 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-Class 


$FPDA; 


REQ  Object-class 


}. 


REQ  Subordinates 


subordinates  {$FixedCompositeBodyGFS}, 
{'270-degrees"  ~  body  layout  A  - 
I'O-degrees'  -  Ixxly  layout  B  - 
i'180-degrees'  -  t>ody  layout  C  --} 

{REQ  #constraint-name  {"6"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJ  ECT_CLASS_!  D_OF 

( FixedCompositeBody)} 

{OBJECT_CLASSJD_OF 

(FixedCompositeBody)} 

{SUB_ID_OF(CompositeCommon)+, 
SUB_ID_OF(BasicFixture)+, 
SUBJD_OF(ColumnFixed)-h. 
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PERM  Imaging-order 


PERM  Application-comments 


SUB_ID_OF(CompositeFixtureFixed)+, 
SUB_ID_OF(VariableCompositeBody)+, 
SUB_ID_OF(SourcedContentFixed)+. 
SUB_ID_OF(ArrangedContentFixed)+}, 
{SUBJD_OF(CompositeCommon)+. 
SUBJD_OF(BasicFixture)+, 
SUBJD_OF(ColumnFixed)+, 
SUBJD_OF(CompositeFixtureFixed)+, 
SUB_ID_OF(VariableCompositeBody)+. 
SUB_ID_OF(SourcedContentFixed)+. 
SUB_I  D_OF(  ArrangedContent  Fixed)+} , 
{REQ  #constraint-name  {"6"}, 
PERM  #extemal-data  {ANY_VALUE}} 


.4.3.9  VariabieCompositeBody 


(ANY-FRAME-FIXED  { 
pENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for- 
PERM  Layout-path 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


REQ  Subordinates 


PERM  Application-comments 


subordinates  {$VariableCompositeBodyGFS}. 
{'270-degrees'  -  body  layout  A  - 
I'O-degrees'   -  body  layout  B  - 
I'lSO-degrees'  -  body  layout  C  -} 

{REQ  #constraint-name  {"7"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(VariabieCompositeBody)} 

{OBJECT_CLASS_ID_OF 

(VariabieCompositeBody)} 

{SUB_ID_OF(SnakingColumns)+. 
SUB_ID_OF(SynchronizedColumns)+, 
SUBJD_OF(BasicFloat)+, 
SUBJD_OF(FootnoteArea)+, 
SUB_I  D_OF(CompositeFloat)-^ , 
SUBJD_OF(Composite  Fixture  Variable)+, 
SUBJD_OF(TableArea)-H, 
SUB_ID_OF(ArrangedContentVariable)+, 
SUBJD_OF(SourcedContentVariable)+}, 

{REQ  #constraint-name  {"7"}, 
PERM  #extemal-data  {ANY_VALUE}} 
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7.4.3.10  ColumnFixed 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
SPDA-FPDA: 

REQ  Position 


}  }. 


{REQ  #fixed-position 

{REQ  #horlzontal-position  {ANY_VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}. 
CASE  SUPERIOR  ({VariableCompositeBody 

I  FixedCompositeBody}  (Layout-path))  OF  { 

{'270-degrees'}:  --  body  layout  A  -- 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-<Jimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies')}. 
REQ  #vertical-dimension 
{REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-size  {  applies  })). 

PERM  Layout-path  {'270-degrees') 

{'0-degrees'}:  -  body  layout  B  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE) 
|REQ  #maximum-size  {'applies'}). 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE) 
|REQ  #maximum-size  {'applies'))). 

REQ  Layout-path  {'0-degrees') 

{'180-degrees  }:  -  tx>dy  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #maximum-size  {'applies')}. 
REQ  #vertical-dimension 
{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'))}. 

REQ  Layout-path  {'180-degrees') 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 
PERM  Imaging-order 
PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Permitted-categories 


{REQ  #constraint-name  {"8"}. 
PERM  #external-data  {ANY_VALUE)) 


{OBJECT_CLASS_ID_OF(ColumnFixed)} 

{OBJECT_CLASS_ID_OF(ColumnFixed)} 

{SUBJD_OF(SpecificBlock)+}. 
{SUBJD_OF(SpecificBlock)+). 
{REQ  #constraint-name  {"8"). 
PERM  #extemal-data  {ANY_VALUE)} 

{ANY_STRING.  .} 
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,4.3.11  ColumnVariable 


IXNY-FRAME-VARIABLE  { 
iENERIC: 
CASE  $DAC  OF  { 
$PDA-FPDA: 

ll  REQ   Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}. 
PERM  #alignment  {ANY_VALUE}. 
PERM  #fill-order  {  normal-order  }}}, 
CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 

{'270-degrees"}:  -  body  layout  A  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #mle-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

PERM  Layout-patti  {'270-degrees'} 


{'0-degrees'}: 
REQ 


-  body  layout  B 
Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}, 

REQ  #vertical-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE}}}. 
{'0-degrees'} 


{'180-degrees'}:  -  tx)dy  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY^VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE}}}, 

REQ  Layout-path  {'180-degrees'} 

}  }. 

REQ    Application-comments         {REQ  #constraint-name  {"9"}, 

PERM  #external-data  {ANY_VALUE}} 


SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 
PERM  Imaging-order 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Permitted-categories 

} 


{OBJECT_CLASSJD_OF(ColumnVariable)} 

{OBJECT_CLASS_ID_OF(ColumnVariable)} 

{SUB_ID_OF(SpecificBlock)-i-}, 
{SUB_ID_OF(SpeciticBlock)+}, 
{REQ  #constraint-name  {"9"}, 
PERM  #external-data  {ANY_VALUE}} 

{ANY_STRING...} 
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7.4.3.12  SnakingColumns 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$SnakingColumnsGFS}. 
REQ  Position  {REQ  #variable-position  { 

PERM#offset  {ANY_VALUE}. 

PERM  #separation  {ANY_VALUE}. 

PERM  #alignment  {ANY_VALUE}. 

PERM  #fill-order  {'normal-order'}}}. 
PERM  Balance  {ANY_VALUE}, 

CASE  SUPERIOR  {VariableCompositeBody(Layout-path))  OF  { 


{■270-degrees'}:  --  body  layout  A  -- 


REQ  Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 
{REQ  #1ixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}. 
REQ  #vertical-dimension 
{REQ  #mle-b  {ANY_VALUE}}}. 

{ '0-degrees'  r  1 80-degrees '} 


{'0-degrees'}: 
REQ 


-  body  layout  B  - 
Dimensions 


PERM  Layout-path 


{REQ  #horizontal-dimension 
{REQ  #mle-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #maximum-si2e  {'applies'}}}, 

{'90-degrees'r270-degrees'} 


{'1 80-degrees'}:  -  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #mle-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}. 
{'270-degrees*} 


PERM  Layout-path 


}  }. 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 


PERM  Application-comments 


{REQ  #constraint-name  {"10"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(Snakingcolumns)} 

{OBJECT_CLASS_ID_OF(Snakingcolumns)} 

{SUB_ID_OF(ColumnVariable)-^, 
SUB_ID_OF(CompositeColumnVariable)-i-. 
SUB_ID_OF(ArrangedContentVariable)-i-, 
SUB_ID_OF(SourcedContent  Variable)-!-}. 
{REQ  #constraint-name  {"10"}, 
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PERM  #extemal-data  {ANY_VALUE}} 


r.4.3.13  SynchronizedColumns 

ANY-FRAME-VARIABLE  { 
I3ENERIC: 

CASE  $DAC  OF  { 
SPDA-FPDA: 

REQ  Generator-for-subordinates  {$SynchronizedColumnsGFS}. 
REQ    Position  {REQ  #variable-position  { 

PERM  #offset  (ANY_VALUE}. 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {  normal-order  }}}, 

CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 


{'270-degrees  }:  ~  body  layout  A  - 

REQ  Dimensions       {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #rule-b  {ANY_VALUE}}}. 
{'270-degrees'} 


PERM  Layout-path 


{'0-degrees'}:  -  body  layout  B 
REQ  Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 
{REQ  #rule-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

{'0-degrees'} 


{'180-degrees'}:  -  body  layout  C  ~ 

REQ  Dimensions       {REQ  #horizontal-dimension 

{REQ  #rule-b{ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

REQ  Layout-path  {'180-degrees'} 

}  }. 

REQ    Application-comments         {REQ  #constraint-name  {"11"}, 

PERM  #external-data  {ANY_VALUE}} 


SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REG  Subordinates 


{OBJECT_CLASS_ID_OF(SynchronizedColumns)} 

{OBJECT_CLASS_ID_OF(SynchronizedColumns)} 

{SUB_ID_OF(ColumnFixed)+, 
SUBJD_OF(CompositeColumnFixed)+, 
S U B_  I  D_OF ( ArrangedContent Fixed)+, 
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SUB_ID_OF(SourceclContentFixed)+}. 
PERM    Application-comments         {REQ  #constraint-name  {"1 1"). 

PERM  #extemal-data  {ANY_ VALUE}} 


7.4.3.14  BasicFloat 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Position  (REQ  #variable-position  ( 

PERM#offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}. 
PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {  normal-order  }}}. 

CASE  SUPERIOR  ({VariableCompositeBody 

I  CompositeColumnVariable  |  CompositeColumnFixed 

I  CompositeFixtureVariable  j  CompositeFixtureFixed}  (Layout-path))  OF  { 

{■270-degrees'}:  -  body  layout  A  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #rule-b  {ANY_VALUE}}}, 
PERM  Layout-path  {'270-degrees'} 

{'0-degrees'}:  -  body  layout  B  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 
REQ  Layout-path  {'0-degrees'} 

{'180-degrees'}: -- body  layout  C -- 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #mle-b  {ANY_VALUE}}, 
REQ  #verlical-dimension 
{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

REQ  Layout -path  {'180-degrees'} 

}  }. 

REQ    Application-comments         {REQ  #constraint-name  {"12"}. 

PERM  #external-data  {ANY  VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF(BasicFloat)} 

$FPDA: 

REQ   Object-class  {OBJECT_CLASS_ID_OF{BasicFloat)} 
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I  REQ  Subordinates 
PERM  Imaging-order 
PERM  Application-comments 

I  ;PECiFIC_AND_GENERIC : 
PERM  Permitted-categories 


'.4.3.15  CompositeFloat 

ANY-FRAME- VARIABLE  { 
iSENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {SCompositeFloatGFS}. 
REQ   Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 

PERM  #separation  {ANY_VALUE}. 

PERM  #alignment  {ANY_VALUE}. 

PERM  #till-order  {  normal-order  }}}. 

CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 

{■270-degrees'}:  -  body  layout  A  - 

REQ  Dimensions        {REQ  #hori2ontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #rule-a  {ANY_ VALUE}}}. 

PERM  Layout-path      {'0-degrees 'I'lSO-degrees'} 

{'0-degrees'}:  -  lx)dy  layout  B  - 

REQ  Dimensions       {REQ  #horizontal-dimension 

{REQ  #mle-a  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}. 

REQ  Layout-path       {'90-degrees  r270-degrees'} 

{'180-degrees'}:  -  lx)dy  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #rule-a  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}. 

REQ  Layout-path       {'90-degrees  r270-degrees'} 

}  }. 

REQ    Application-comments         {REQ  #constraint-name  {"13"}, 

PERM  #external-data  {ANY_ VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF{CompositeFloat)} 

$FPDA; 


{SUBJD_OF(SpecificBlock)+}, 
{SUBJD_OF(SpecificBlock)-t-}, 
{REQ  #constraint-name  {"12"}, 
PERM  #external-data  {ANY_VALUE}} 

{ANY_STRING...} 
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}. 


REQ   Object-Class  {OBJECT_CLASS_ID_OF(CompositeFloat)} 


REQ  Subordinates 


PERM  Application-comments 


{SUBJD_OF(CompositeFlxtureVariable)+, 

SUB_ID_OF(TableArea)+. 

SUB_ID_OF(BasicColumn)+, 

SUBJD_OF(ArrangedContentVariable)+, 

SUBJD_OF(SourcedContentVariable)+}. 
{REQ  #constraint-name  {"13"}, 

PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.16  BasicCoiumn 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}. 
PERM  #separation  {ANY_VALUE}. 
PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {'normal-order'}}}, 

CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 

{'270-degrees'}:  --  body  layout  A  -- 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #mle-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimensiGn  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-size{'applies'}}}, 

PERM  Layout-path  {'270-degrees'} 

{'0-degrees'}:  -  body  layout  B  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-si2e{'applies'}}, 
REQ  #vertical-dimension 
{REQ  #1ixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}}. 

REQ  Layout-path  {'0-degrees'} 

{'180-degrees'}:  -  Ixjdy  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #njle-b  {ANY_VALUE} 
|REQ  #maximum-size{'applies'}}, 
,  REQ  #venical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}}, 
REQ  Layout-path  {'180-degrees'} 
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)  }. 

REO  Application-comments 

PECIFIC: 
CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REO  Object-class 

}. 

REQ  Subordinates 

PERM  Application-comments 

PECIFIC.  AND_GENERIC : 
PERM  Permitted-categories 


{REQ  #constraint-name  {"14"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASSJD_OF(BasicColumn)J 

{OBJECT_CLASS_iD_OF(BaslcColumn)} 

{SUB_ID_OF(SpeciflcBlock)+}. 
{REQ  #constraint-name  {"14"}, 
PERM  #extemal-data  {ANY_ VALUE}} 

{ANY_STRING...} 


.4.3.17  FootnoteArea 

ANY-FRAME-VARIABLE  { 
ENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Position 


{REQ  #variable-positlon  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {'reverse-order'}}}. 


CASE  SUPERIOR  ({VariableCompositeBody 

I  CompositeColumnVariable  |  CompositeColumnFixed 

I  CompositeFixtureVariable  |  CompositeFlxtureFixed}  (Layout-path))  OF  { 

{■270-degrees'}:  -  body  layout  A  - 

REQ   Dimensions       {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}. 
REQ  #vertical-dimension 
{REQ  #njle-b  {ANY_VALUE}}}. 

PERM  Layout-path  {'ayo-degrees'} 


{'0-degrees'}:  -  body  layout  B  - 

REQ   Dimensions       {REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}. 
REQ  #vertical-dimension 
{REQ  #tixed-dimension  {ANY_VALUE} 
I  REQ  #maximum-size  {'applies'}}}, 

REQ  Layout-path  {'O-degrees'} 


{'180-degrees'}:  -  body  layout  C  - 

REQ   Dimensions       {REQ  #horizontal-dimension 

{REQ  #mle-b  {ANY_VALUE}}. 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
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|REQ  #maximum-size  {'applies'})}, 
REQ   Layout-path  {'ISO-degrees'} 

)  }. 

REQ    Permitted-categories  {$FOOTNOTECATEGORY}, 
-  For  example. 

For  CompositeBody  "Footnote-1" 
For  SnakingColumns  "Footnote-2" 
For  SynchronizedColumns      "Footnote-3".  "Footnote-4". 

"Footnote-5" 

For  ComposlteFixture  "Footnote-6" 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ   Object -class 

). 

REQ  Subordinates 

PERM  Permitted-categories 

PERM  Application-comments 


{REQ  #constraint-name  {"15"}. 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASSJD_OF(FootnoteArea)} 

{OBJECT_CLASS_ID_OF(FootnoteArea)} 

{SUB_ID_OF(Speci<icBlock)+}, 
($FOOTNOTECATEGORY}. 
{REQ  #constraint-name  {"15"}. 
PERM  #external-data  {ANY_VALUE}}} 


7.4.3.18  ArrangedContentFixed 


:ANY-FRAME-FIXED  { 
GENERIC; 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for- 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


}. 


REQ  Subordinates 
PERM  Imaging-order 
PERM  Application-comments 


subordinates  {<construction-expr>::= 

SEQ{OBJECT_CLASS_ID_OF(GenericBlock).  .)}}. 
[REQ  #constraint-name  {"16"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(ArrangedContentFixed)} 

{OBJECT_CLASS_ID_OF 

(ArrangedContentFixed)} 

{SUBJD_OF(GenericBlock)+}. 
(SUBJD_OF(GenericBlock)-i-}, 
{REQ  #constraint-name  {"16"}, 
PERM  #external-data  {ANY_VALUE}} 
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.4.3.1 9  ArrangedContentVariable 


<VNY-FRAME-VARIABLE  { 
3ENERIC: 
CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for 

REQ  Position 


REQ  Dimensions 


}. 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


subordinates  {<construction-expr>::= 

SEQ(OBJECT_CLASS_ID_OF(GenencBlock)...)}. 
{REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 

PERM  #separation  {ANY_ VALUE}, 

PERM  #alignment  {ANY_VALUE}, 

PERM  #fill-order  {  normal-order  }}}. 
{REQ  #hori2ontal-dimension 

{REQ  #fixed-dimension  {ANY__VALUE}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}} 

{REQ  #constraint-name  {"17"}. 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(ArrangedContentVariable)} 

{OBJECT_CLASS_ID_OF 

(ArrangedContentVariable)} 


REQ  Subordinates 
PERM  Imaging-order 
PERM  Application-comments 


{SUBJD_OF(GenericBlock)+}. 
{SUB_ID_OF(GenericBlock)+}. 
{REQ  #constraint-name  {"17"}, 
PERM  #external-data  {ANY_VALUE}} 


7.4.3.20  SourcedContentFixed 


ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
SPDA-FPDA: 
REQ 
REQ 


Logical -source 
Position 


REQ  Dimensions 


{OBJECT_CLASS_ID_OF(CommonContent)}. 
{REQ  #tixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}. 
{REQ  #horizontal-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE}}. 

REQ  #vertical-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}}, 


CASE  SUPERIOR  ({CompositeHeader  |  CompositeFooter  |  TableHeader 
I  FixedCompositeBody  |  CompositeCommon 
I  SynchronizedColumns}  (Layout-path))  OF  { 
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{'270-degrees'}:  --  H/F  layout  A1  or  B2  when  the  immediate  superior  is 

CompositeHeader,  CompositeFooter  or  TableHeader.  or  - 
--  tX3dy  layout  A  when  the  immediate  superior  is 
FixedCompositeBody.  CompositeCommon  or 
SynchronizedColumns -- 
PEBM  Layout-path      {'270-degrees'   -  H/F  layout  A1  or  body  layout  A 

1*1 80-degrees'}  -  H/F  layout  82  " 

{'ISO-degrees'}:  -  H/F  layout  81  when  the  immediate  superior  is 

CompositeHeader  or  CompositeFooter.  or - 

-  tXKjy  layout  C  when  the  immediate  superior  is 
FixedCompositeBody,  CompositeCommon  or 
SynchronizedColumns  - 

REQ  Layout-path       {'ISO-degrees'}  -  H/F  layout  81  or  body  layout  C 

{'  0-degrees'}:  -  H/F  layout  A2  when  the  immediate  superior  is 

CompositeHeader  or  CompositeFooter,  or  -- 

-  body  layout  B  when  the  immediate  superior  is 
FixedCompositeBody,  CompositeCommon  or 
SynchronizedColumns  - 

PERM  Layout-path      {'270-degrees'    -  H/F  layout  A2  - 

I'O-degrees'}  -  t)ody  layout  8  ~ 

)  }. 

REQ    Application-comments         {REQ  #constraint-name  {"IS"}, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF 

(SourcedContentFixed)} 

$FPDA: 

REQ   Object-class  {OBJECT_CLASS_ID_OF 

(SourcedContentFixed)} 

}. 

REQ    Subordinates  {SUB_ID_OF(Specific8lock)+}, 
PERM   Application-comments        {REQ  #constraint-name  {"IS"}, 

PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.21  SourcedContentVariable 

:ANY-FRAME-VARIA8LE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Logical-source  {OBJECT_CLASS_ID_OF{CommonContent)}, 
REQ  Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}. 

PERM  #separation  {ANY_VALUE}, 

PERM  #alignment  {ANY_VALUE}. 

PERM  #fill-order  {  normal-order*}}}, 

CASE  SUPERIOR  ({CompositeHeader  |  CompositeFooter  |  VariableCompositeBody 
I  CompositeColumnVariable  |  CompositeColumnFixed  |  CompositeCommon 
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I  SnakingColumns  |  CompositeFloat}  (Layout-path))  OF  { 


{'270-degrees'}: 


REO  Dimensions 


-  H/F  layout  A1  or  B2  wtien  the  immediate  superior  is 
CompositeHeader  or  CompositeFooter,  or  - 
--  body  layout  A  when  the  immediate  superior  is 
VariableCompositeBody.  CompositeColumnVariable, 
CompositeColumnFixed  or  CompositeCommon,  or  -- 
--  body  layout  B  or  C  when  the  immediate  superior  is 
SnakingColumns  or  CompositeFloat  -- 


PERM  Layout-path 


{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #rule-b  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}, 

REQ  #vertical-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE} 

|REQ  #rule-b  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}, 
{'270-degrees'   -  H/F  layout  A1  or  body  layout  A 
ri80-degrees'   -  H/F  layout  B2  or  body  layout  C 
I'O-degrees'}   -  body  layout  B  - 


{'180-degrees'}: 


--  H/F  layout  B1  when  the  immediate  superior  is 
CompositeHeader  or  CompositeFooter,  or  - 
--  body  layout  C  when  the  immediate  superior  is 
VariableCompositeBody,  CompositeColumnVariable, 
CompositeColumnFixed  or  CompositeCommon,  or  -- 
--  body  layout  A  when  the  immediate  superior  is 
SnakingColumns  or  CompositeFloat  - 


REQ  Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #rule-b  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #mle-b  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}, 
{'180-degrees'   -  H/F  layout  B1  or  Ijody  layout  C 
r270-degrees'}  -  body  layout  A  - 


{'  0 -degrees'}: 


-  H/F  layout  A2  when  the  immediate  superior  is 
CompositeHeader  or  CompositeFooter,  or  - 

-  bo6y  layout  B  when  the  immediate  superior  is 
VariableCompositeBody,  CompositeColumnVariable, 
CompositeColumnFixed  or  CompositeCommon,  or  - 

-  iDOdy  layout  A  when  the  immediate  superior  is 
SnakingColumns  or  CompositeFloat  - 


REQ  Dimensions 


PERM  Layout-path 


{REQ  #horizontai-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #ajle-b  {ANY_VALUE}} 

|REQ  #maximum-size  {'applies'}}, 

REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #rule-b  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}, 
{'270-degrees'  -  H/F  layout  A2  or  lx)dy  layout  A 
I'O-degrees'}  -  body  layout  B  - 
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{'90-degrees'}:  --  body  layout  B  when  the  immediate  superior  is 

SnakingColumns,  or  -- 

--  t)ody  layout  B  or  C  when  the  immediate  superior 
Composite  Float  -- 
REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE) 
|REQ  #maximum-size  {  applies  }}. 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_ VALUE} 
|REQ  #njle-b  {ANY_VALUE}}}. 
PERM  Layout-path      {'0-degrees'  --  t)ody  layout  B  -- 

I'leO-degrees'}  --  tnxly  layout  C  -- 

}  }. 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Application-comments 


{REQ  #constraint-name  {"19"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(Sou  rcedCo  ntent  Variable)} 

{OBJECT_CLASS_ID_OF 

(Sou  rcedCo  ntent  Variable)} 

{SUB_ID_OF(SpectficBlock)+}. 
{REQ  #constraint-name  {"19"}. 
PERM  #extemal-data  {ANY_ VALUE)} 


7.4.3.22  CompositeFixtureVariabie 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {$CompositeFixtureVariableGFS}, 
REQ   Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}. 

PERM  #separation  {ANY_VALUE}. 

PERM  #alignment  {ANY_VALUE}. 

PERM  #fill-order  {  normal-order  }}}. 

CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 

{'270-degrees'}:  -  body  layout  A  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'} 
|REQ  #rule-b  {ANY_VALUE}}. 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #mle-b  {ANY_VALUE}}}. 
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PERM  Layout-path 


{•27O-degreesT18O-degre0S' 
I'O-degrees'} 


{'0-degrees'}:  --  tx)dy  layout  B  -- 

REQ  Dimensions       {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #aile-b  {ANY_VALUE}}. 
REQ  #vertical -dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'} 
|REQ  #rule-b  {ANY_VALUE}}}. 
{'O-degrees'l'90-degrees' 
r270-degrees'} 


REQ  Layout-path 


}  }. 


{'180-degrees'}:  -  body  layout  C  - 

REQ  Dimensions       {REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_ VALUE} 
|REQ  #rule-b  {ANY_VALUE}}. 
REQ  #veilical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'} 
|REQ  #rule-b  {ANY_VALUE}}}. 
{'1 80-degrees  r270-degrees'} 


REQ  Layout-path 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-Class 


$FPDA: 


REQ  Object-class 


REQ  Subordinates 


PERM  Application-comments 


{REQ  #constraint-name  {"20"}, 
PERM  #extemal-data  { AN Y_ VALUE}} 


{OBJECT_CLASS_ID_OF 

(CompositeFixtureVariable)} 

{OBJECT_CLASS_ID_OF 

(CompositeFixtureVariable)} 

{SUB_ID_OF(BasicFloat)-h. 
SUB_ID_OF(FootnoteArea)+, 
SUB_ID_OF(CompositeArtwork)+, 
SUB_ID_OF(FormArea)+}, 
{REQ  #constraint-name  {"20"}. 
PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.23  CompositePixtureFixed 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {$CompositeFixtureFixedGFS}, 
REQ   Position  {REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}. 
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CASE  SUPERIOR  (FixedCompositeBody{Layout-path))  OF  { 


{'270-clegrees'};  --  body  layout  A  - 

REQ  Dimensions        {REG  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #1ixed-dimenston  {ANY_VALUE} 
|REQ  #njle-b  {ANY_VALUE}}}. 
{'270-degrees  ri80-degrees' 
I'O-degrees'} 


PERM  Layout-path 


{'0-degrees'}:  --  body  layout  B  -- 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_ VALUE} 
|REQ  #rule-b  {ANY_VALUE}}. 
REQ  #vertical-dimension 
{REQ  #tixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 
{'O-degrees'l'QO-degrees' 
r270-degrees'} 


REQ  Layout-path 


{■180-degrees'}:  -  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #mle-b  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #1ixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {  applies*}}}, 
{'1 80-degrees'r270-degrees'} 


REQ  Layout-path 
}  }. 

REQ  Application-comments 


SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


}. 


REQ  Subordinates 


PERM  Application-comments 


{REQ  #constraint-name  {"21"}, 
PERM  #extemal-data  {ANY_ VALUE}} 


{OBJECT_CLASS_ID_OF 

(CompositeFixtureFixed)} 

{OBJECT_CLASS_ID_OF 

(CompositeFixtureFixed)} 

{SUB_ID_OF(BasicFloat)-t-. 

SUB_ID_OF(FootnoteArea)-i-, 

SUB_ID_OF(CompositeArtwork)+. 

SUBJD_OF(FormArea)+}, 
{REQ  #constraint-name  {"21"}, 

PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.24  BasicFlxture 


:ANY-FRAME-VARIABLE  { 
GENERIC: 
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CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Position  {REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 
REQ  #vertlcal-position  {ANY_VALUE}}}, 

-  Note  that  values  of  position  may  usually  be  "0"  for  overlapping  figure.  -- 

REQ   Dimensions       {REQ  #horizontal-dimension 

{REQ  #fixed-climension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}. 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_ VALUE} 
|REQ  #rule-b  {ANY_VALUE}}}. 

CASE  SUPERIOR  ({FixedCompositeBody  |  CompositeArtv>^ork}  (Layout-path))  OF  { 

{'270-degrees'}:  --  tx)dy  layout  A 

PERM  Layout-path  {'270-degreesT180-degrees') 

{'0-degrees'}:  -  body  layout  B  - 

REQ  Layout-path  {'0-degreesT270-degrees'} 

{'180-degrees'};  -  body  layout  C  - 

PERI^  Layout-path  {'180-degreesT270-degrees'} 

}  ). 

REQ    Application-comments         {REQ  #constraint-name  {"22"}, 

PERM  #extemal-data  {ANY_VALUE}} 
SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF(BasicFixture)} 

$FPDA: 

REQ   Object-class  {OBJECT_CLASS_ID_OF(BasicFixture)} 
}. 

REQ    Subordinates  {SUB_ID_OF(SpecificBlock)+}. 
PERM   Application-comments        {REQ  #constraint-name  {"22"}, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC,  AND_GENERIC : 

PERM   Pemiitted-categories  {ANY_STRING ..} 

} 


7.4.3.25  CompositeColumnFixed 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {$CompositeColumnFixedGFS}, 
REQ   Position  {REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 

REQ  #verlical-position  {ANY_VALUE})}. 

CASE  SUPERIOR  (VariableCompositeBody (Layout-path))  OF  { 
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('270-degrees'};  --  body  layout  A  -- 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed<limension  (ANY_VALUE} 
|REQ  #maximum-si2e  ('applies'}}. 
REQ  #vertical-dimension 
{REQ  #rute-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}. 
PERM  Layout-path  {■270-degrees'} 


{'0-degrees'}: 
REQ 


-  body  layout  B 
Dimensions 


REQ  Layout -path 


{REQ  #horizontal-dimension 
{REQ  #njle-b  {ANY_VALUE} 
|REQ  #maximum-slze  {'applies'}}, 

REQ  #vertical-dimension 
{REQ  #1ixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 

{'O-degrees] 


{'180-degrees'}:  -  body  layout  C 


REQ  Dimensions 


}  }. 


REQ  Layout-path 


{REQ  #horizontal-dimension 
{REQ  #maximum-size  {'applies'}}, 

REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}. 

{■180-degrees'} 


REQ  Application-comments 


SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM 


Object-Class 


$FPDA: 


REQ  Object-class 


}. 


REQ  Subordinates 


PERM  Application-comments 


{REQ  #constraint-name  {"23"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(CompositeColumnFixed)} 

{OBJECT_CLASS_ID_OF 

(CompositeColumnFixed)} 

{SUB_ID_OF(BasicFloat)-H, 

SUBJD_OF(CompositeFloat)-t-, 

SUBJD_OF(FootnoteArea)+, 

SUB_ID_OF(Composi1eFixtureVariable)-i-, 

SUBJD_OF(TableArea)-h, 

SUBJD_OF(ArrangedContentVariable)-(-. 

SUB_ID_OF(SourcedContent  Variable)-!-}, 
{REQ  #constraint-name  {"23^'}, 

PERM  #external-data  {ANY_VALUE}} 


7.4.3.26  CompositeColumnVariable 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 
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REQ   Generator-for-subordinates  {SCompositeColumnVariableGFS}. 

REQ   Position  {REQ  #variable-posilion  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  (  normal-order  }}}. 

CASE  SUPERIOR  (VariableCompositeBody(Layout-path))  OF  { 

{'270-degrees'}:  --  body  layout  A  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 
{REQ  #rule-b  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 
{'270-degrees'} 


PERM  Layout-path 


{'0-degrees'}:  -  body  layout  B 
REQ  Dimensions 


REQ  Layout-path 


{REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}, 

REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}, 
{'0-degrees'} 


{'180-degrees'}:  ~  body  layout  C  - 

REQ  Dimensions        {REQ  #horizontal-dimension 

{REQ  #rule-b  (ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}, 
REQ  #vertical-dimension 
{REQ  #fixed-dimension  {ANY_VALUE}}}, 
{'180-degrees'} 


REQ  Layout -path 
}  }. 

REQ  Application-comments 


SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


}. 


REQ  Subordinates 


PERM  Application-comments 


{REQ  #constraint-name  {"24"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(CompositeColumnVariable)} 

{OBJECT_CLASS_ID_OF 

(CompositeColumnVariable)} 

{SUBJD_OF(BasicFloat)-(-, 

SUB_ID_OF(CompositeFloat)-i-, 

SUBJD_OF(FootnoteArea)-i-, 

SUBJD_OF(CompositeFixtureVariable)+, 

SUBJD_OF(TableArea)+, 

SUB_ID_OF(ArrangedContentVariable)-H, 

SUB_ID_OF(SourcedContentVahable)-h}, 
{REQ  #constraint-name  ("24"}, 

PERM  #extemal-data  (ANY_VALUE}} 
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7.4.3.27  CompositeCommon 

:ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ    Generator-for-subordinates  {$CompositeCommonGFS}, 

CASE  SUPERIOR  (FixedCompositeBody(Layout-path))  OF  { 

{'270-degrees'}:  --  body  layout  A  -- 

PERM  Layout-path  {•270-degrees'} 

{'0-degrees'}:  -  body  layout  B  -- 

PERM  Layout-path  {'O-degrees'} 

{'180-degrees'}:  -  body  layout  C  - 

PERM  Layout-path  {'180-degrees"} 

}}. 

REQ    Application-comments         {REG  #constraint-name  {"25"}, 

PERM  #extemal-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF(CompositeComnrx)n)} 

$FPDA: 

REQ   Object-class  {OBJECT_CLASS_ID_OF(ComposlteCommon)} 

}. 

REQ    Subordinates  {SUBJD_OF(SourcedContentFixed)+, 

SUB_ID_OF(ArrangedContentFixed)+. 
'  '  '  SUB_ID_OF(SourcedContentVariable)+. 

SUB_ID_OF(ArrangedContentVarlable)+}. 
PERM   Imaging-order  {SUB_ID_OF(SourcedContentFixed)+, 

SUB_ID_OF(ArrangedContentFlxed)+}, 
PERM   Application-comments        {REQ  #constraint-name  {"25"}. 

PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.28  Composite  Artwork 

;ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$CompositeArtworkGFS}, 

REQ   Position  {REQ  #variable-position  { 

PERM#offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}. 
PERM  #f ill-order  {  normal-order*}}}. 

REQ   Dimensions       {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_ VALUE}}. 
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REQ  #vertical-dimension 

{REQ  #fixecl-dimension  {ANY_VALUE} 
|REQ  #rule-b  {ANY_VALUE}}}, 

CASE  SUPERIOR  ({CompositeFixture Variable  |  CompositeFixtureFixed} 

(Layout-path))  OF  { 

{'270-degrees'}: 

PERM  Layout-path  {'270-degrees'} 
{'0-degrees'}: 

REQ  Layout-path  {'0-degrees'} 

{'180-degrees'}: 

REQ  Layout -path  {'180-degrees'} 

}}■ 

REQ    Application-comments         {REQ  #constraint-name  {"26"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class  {OBJECT_CLASS_ID_OF(Compos!teArtwork)} 

$FPDA: 

REQ   Object-class  {OBJECT_CLASS_ID_OF(CompositeAr1work)} 

}. 

REQ  Subordinates  {SUB_ID_OF(BasicFixture)-i-}, 
PERM  Imaging-order  {SUBJD_OF(BasicFixture)+}, 
PERM   Application-comments        {REQ  #constraint-name  {"26"}, 

PERM  #external-data  {ANY_ VALUE}} 

} 


7.4.3.29  BasicHeader 


:ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Logical-source 

}. 

PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Application-comments 


{OBJECT_CLASS_ID_OF(CommonContent)} 

{'270-degrees'  ~  H/F  layout  A1  ~ 
I'leo-degrees'  -  H/F  layout  B1  -}, 
{REQ  #constraint-name  {"27"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF{BasicHeader)} 

{OBJECT_CLASS_ID_OF(BasicHeader)} 

{SUB_ID_OF(SpecificBlock)-h}, 
{REQ  #constraint-name  {"27"}. 
PERM  #extemal-data  {ANY_VALUE}} 
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7.4.3.30  BasicFooter 


:ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Logical-source 

}. 

PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Application-comments 


{OBJECT_CLASS_ID_OF(CommonContent)} 

{•270-degrees*  -  H/F  layout  A1  -- 
ri80-degrees'  -  H/F  layout  B1  --}. 
{REQ  #constraint-name  {"33"}. 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(BasicFooter)} 

{OBJECT_CLASSJD_OF(BasicFooter)} 

{SUB_ID_OF(SpecificBlock)-H}, 
{REQ  #constraint-name  {"33"}. 
PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.31  BasicBody 

:ANY-FRAME-FIXED  { 
GENERIC: 

PERM  Layout-path 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Application-comments 


{■270-degrees'  -  body  layout  A  - 
I'O-degrees'   -  body  layout  B  - 
I'lSO-degrees'  -  body  layout  C  -}, 
{REQ  #constraint-name  {"28"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(BasicBody)} 

{OBJECT_CLASS_ID_OF(BasicBody)} 

{SUBJD_OF(SpecificBlock)-f}. 
{REQ  #constraint-name  {"28"}. 
PERM  #extemal-data  {ANY_VALUE}} 


7.4.3.32  GenericBlock 


GENERIC: 

REQ  Object-type 
REQ  Object-class-identifier 
REQ  Content-architecture-class 
PERM  Content-generator 


{'block'}. 
{ANY_VALUE}, 

{$FC  I  $FPC  I  $FPR  I  $FPG  }. 
{$GENERICBLOCKREF}, 
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{CONTENTJD_OF(Character-content-portion)+ 

I  CONTENT_ID_OF(Raster-graphics-content-portion) 

I  CONTENT_ID_OF(Geometric-graphics-content-portion) }. 

{STYLEJD_0F(PStyle1) 

I  STYLEJD_0F(PStyle2) 

!  STYLEJD_0F(PStyle3)}, 

{ANY_VALUE}, 

{REQ  #constraint-name  {"29"}, 
PERM  #external-clata  {ANY_VALUE}} 

{'block'}, 
{ANY_VALUE}, 


{OBJECT_CLASSJD_OF{GenericBlock)} 

{OBJECT_CLASS_ID_OF(GenericBlock)} 

{STYLEJD_0F(PStyle1) 
I  STYLEJD_0F(PStyle2) 
I  STYLE_ID_0F(PStyle3)}, 
PERM  Content-architecture-class    {$FC  |  $FPC  |  $FPR  |  $FPG  }, 
CASE  GenericBlock  (Object-class)  OF  { 
VOID: 

REQ   Content-portions  {CONTENT_ID_OF(Character-content-portion)+ 

|CONTENT_ID_OF(Raster-graphics-content-portion) 
|CONTENT_ID_OF(Geometric-graphics-content-portion)} 

}. 

PERM  Presentation-attributes  { 
PERM  #character-attnbutes  { 


PERM 

#alignment 

{ANY  VALUE}, 

PERM 

#character-fonts 

{ANY_VALUE}, 

PERM 

#character-path 

{ANY  VALUE}, 

PERM 

#character-spacing 

{ANY  VALUE}, 

PERM 

#character-orientation 

{ANY  VALUE}, 

PERM 

#code-extension-announcers 

{$CDEXTEN}, 

PERM 

#tirst-line-oftset 

{ANY  VALUE}, 

PERM 

#graphic-character-sets 

{$PERMIT-GRCHAR}, 

PERM 

#graphic-character-subrepertoire  {ANY_VALUE}, 

PERM 

#graphic-renclition 

{SGRAPHICRENDITIONS}, 

PERM 

#itemisation 

{ANY  VALUE}, 

PERM 

#kerning-ottset 

{ANY  VALUE}, 

PERM 

#line-layout-table 

{ANY_VALUE}. 

PERM 

#line-progression 

{ANY_VALUE}. 

PERM 

#iine-spacing 

{ANY_VALUE}, 

PERM 

#pairwise-kerning 

{ANY  VALUE}, 

PERM 

#formatting-inclicator 

{ANY  VALUE}, 

PERM 

#initial-offset 

{ANY  VALUE} 

} 

}. 

PERM   Application-comments        {REQ  #constraint-name  {"29"}, 

PERM  #external-data{ANY_VALUE}} 

SPECIFIC_AND_GENERIC: 

PERM  Position  {REQ  #fixecl-position 

{REQ  #horizontal-position  {ANY_VALUE}. 


PERM  Content-portions 


PERM  Presentation-style 


PERM  Resource 

REQ  Application-comments 

SPECIFIC: 

REQ  Object-type 
REQ  Object-identifier 
CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

PERM  Presentation-style 
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PERM  Dimensions 


PERM  Transparency 
PERM  Colour 
PERM  Border 

PERM  User-readable-comments 
PERM  User-visible-name 


REQ  #>/emcal-position  {ANY_VALUE}}}. 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 
REQ  #venical-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE}}}, 
{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_STRING}. 
{ANY_STRING} 


7.4.3.33  Specific  Block 


{ 

SPECIFIC: 

REQ  Object-type 
REQ  Object-identifier 
REQ  Content-portions 


PERM  Position 


PERM  Dimensions 


PERM  Presentation-style 


PERM  Content-architecture-class 
PERM  Presentation -attributes 
PERM  #character-attributes  { 


{'block'}, 
{ANY_VALUE}. 

{CONTENTJD_OF(Character-content-portion)+ 
|CONTENT_ID_OF{Raster-graphics-content-portion) 
|CONTENT_ID_OF(Geometric-graphics-content-portion)}, 
{REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 

REQ  #vertical-position  {ANY_VALUE}}}. 
{REQ  #horizontal-dimension 

{REQ  #fixed-dlmension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}}. 
{STYLE_ID_0F(PStyle1) 
I  STYLE_ID_0F(PStyle2) 
I  STYLE_ID_0F(PStyle3) 
I  STYLE_ID_0F(PStyle4)}, 
{$FC  I  $FPC  I  $FPR  I  $FPG}. 
{ 


PERM 

#aiignment 

{ANY  VALUE}. 

PERM 

#character-fonts 

{ANY_VALUE}, 

PERM 

#character-path 

{ANY_VALUE}, 

PERM 

#character-spacing 

{ANY_VALUE}, 

PERM 

#character-orientation 

{ANY_VALUE). 

PERM 

#code-extension-announcers 

{$CDEXTEN}, 

PERM 

#first-line -offset 

{ANY_VALUE}, 

PERM 

#graphic-character-sets 

{$PERMIT-GRCHAR  }. 

PERM 

#graphic-character-subrepertoire  {ANY_VALUE}. 

PERM 

#graphic-rendition 

{SGRAPHICRENDITIONS}. 

PERM 

#itemisation 

{ANY_VALUE}, 

PERM 

#kernjng-offset 

{ANY_VALUE}, 

PERM 

#line-layout-table 

{ANY_VALUE}, 

PERM 

#line-progression 

{ANY_VALUE}, 

PERM 

#line-spacing 

{ANY  VALUE}, 

PERM 

#pairwise-kerning 

{ANY  VALUE}. 

PERM 

#formatting-indicator 

{ANY  VALUE}. 

PERM 

#init!al-offset 

{ANY_VALUE} 
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}. 

PERM  Transparency  {ANY_VALUE}, 

PERM  Colour  {ANY_VALUE}, 

.  PERM  Border  {ANY_VALUE  }, 

PERM  User-readable-comments  {ANY_STRING}, 

PERM  User-visible-name  {ANY_STRINGi, 

PERM  Application-comments  {REQ  #constraint-name  ("30"}, 

PERM  #external-data  {ANY_VALUE}} 

} 


7.4.3.34  FormArea 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates 


REQ  Position 


{$FormAreaGFS}}. 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 


PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 

} 


{REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {  normal-order  }}}, 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 

REQ  #verlical-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}}, 

{'270-degrees'}, 

{REQ  #constraint-name  {"31"}. 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(FormArea)} 
{OBJECT_CLASSJD_OF(FormArea)} 

{SUB_ID_OF(ArrangedContentFixed)-i-, 

SUB_ID_OF(FormEntryArea)-H, 

SUBJD_OF(EntryGroupArea)+}, 
{ANY_VALUE}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 

REQ  #verticai-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{REQ  #constraint-name  {"31"}, 

PERM  #external-data  {ANY_VALUE}} 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 
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7.4.3.35  EntryGroupArea 


:ANY-FRAME-FIXED  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-lor-subordinates 


{$EntryGroupAreaGFS} 


}. 

REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-Class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 


PERM  Position 
PERM  Dimensions 


PERM  Imaging-order 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 


{REQ  #1ixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}. 
{REQ  #horizontal-dimension 

{REQ  #fixedKlimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}, 
{■270-degrees'}, 

{REQ  #constraint-name  {"35"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(EntryGroupArea)} 

{OBJECT_CLASS_ID_OF(EntryGroupArea)} 

{SUBJD_OF(ArrangedContentFixed)+. 
SUB_ID_OF(FormEntryArea)+, 
SUB_ID_OF(EntryGroupArea)+}. 
{ANY_VALUE}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}, 
{ANY_VALUE}, 

{REQ  #constraint-name  {"35"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE} 


7.4.3.36  TableArea 

ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$TableAreaGFS} 

}. 

REQ    Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}. 
PERM  #separation  {ANY_VALUE}. 
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REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 


PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Transparency 
PERM  Colour 
PERM  Border 

) 


PERM  #alignment  {ANY_VALUE}, 
PERM  #fill-order  {  normal-order  }}}. 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimenston 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #fixed-dimenslon  {ANY_VALUE}}}, 

{•270-degrees'}. 

{REQ  #constraint-name  {"36"}, 

PERM  #external-data  {ANY_VALUE}}  , 


{OBJECT_CLASS_ID_OF(TableArea)} 
{OBJECT_CLASSJD_OF(TableArea)} 

{SUBJD_OF(RowArea)+, 

SUBJD_OF(TableLabel)+, 

SUB_ID_OF(TableHeader)}, 
{ANY_VALUE}, 
{REQ  #honzontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}, 
{REQ  #constraint-name  {"36"}, 

PERM  #external-data  {ANY_VALUE}} 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 


7.4.3.37  TableHeader 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA; 

REQ  Generator-for-subordinates 


{$TableHeaderGFS} 


REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 


{REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}, 

PERM  #separation  {ANY_VALUE}. 

PERM  #alignment  {ANY_VALUE}. 

PERM  #fill-order  {  normal-order  }}}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #1ixed-dimension  {ANY_VALUE}}}. 
{'270-degrees'}, 

{REQ  #constraint-name  {"34"}, 
PERM  #external-data  {ANY_VALUE}} 
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SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Transparency 
PERM  Cotour 
PERM  Border 


{OBJECT_CLASS_ID_OF(TableHeader)} 

{OBJECT_CLASSJD_OF(TableHeader)} 

{SUB_ID_OF(SourcedContentFixed)+}. 

{ANY_VALUE}. 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE})}. 
{REQ  #constraint-name  {"34"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_VALUE} 


} 


7.4.3.38  TableLabel 

:ANY-FRAME-VARIABLE  { 
GENERIC; 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {$TableLabelGFS} 


}. 

REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-Class 

$FPDA: 

REQ  Object-Class 

). 

REQ  Subordinates 

PERM  Position 
PERM  Dimensions 


{REQ  #variable-position  { 

PERM  #otfset  {ANY_VALUE}, 

PERM  #separation  {ANY_VALUE). 

PERM  #alignment  {ANY_VALUE}. 

PERM  #fill-order  {'normal-order')}}, 
{REQ  #horizontal-dimension 

{REQ  #ftxed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #mle-b  {ANY_VALUE} 

|REQ  #fixed-dimension  {ANY_VALUE}}}. 
{•270-degrees'}, 

{REQ  #constraint-name  {"37"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(Tab!eLabel)} 

{OBJECT_CLASS_ID_OF{TableLabel)} 

{SUB_ID_OF(TableLabelContent)+, 
SUB_ID_OF(CompositeTableLabel)}. 
{ANY_VALUE}. 
{REQ  #hori2ontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 
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PERM  Application-comments 

SPECIFIC.  AND_GENERIC : 
PERM  Transparency 
PERM  Colour 
PERM  Border 

} 


REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{REQ  #constraint-name  {"37"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE} 


7.4.3.39  CompositeTableLabel 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {$CompositeTableLabelGFS} 


}. 

REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-Class 


$FPDA: 


REQ  Object-Class 


}. 


REQ  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Imaging-order 
PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 

} 


{REQ  #fixed -position  { 

REQ  #horizontai-position  { AN Y_ VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}, 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 

REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #tixed-dimension  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}. 

{'270-degrees'}, 

{REQ  #constraint-name  {"38"}. 

PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(CompositeTableLabel)} 

{OBJECT_CLASS_ID_OF 

(CompositeTableLabel)} 

{SUBJD_OF(LabelComponent)+}, 

{ANY_VALUE}. 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{ANY_VALUE}, 

{REQ  #constraint-name  ("38"}, 
PERM  #external-data  {ANY_VALUE}} 


{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE} 
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7.4.3.40  LabelComponent 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ   Generator-for-subordinates  {$LabelComponentGFS} 

I 

REQ   Position  {REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}. 
PERM  #separation  {ANY_VALUE}. 
PERM  #alignment  {ANY_VALUE). 
PERM  #fill-order  {'normal-order'}}}. 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_ VALUE}}, 
REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 
|REQ  #fixed-dimension  {ANY_VALUE} 
|REQ  #maximum-size  {'applies'}}}, 
{■270-degrees'}, 

{REQ  #constraint-name  {"39"}, 
PERM  #external-data  {ANY_VALUE}} 


REQ  Dimensions 


PERM  Layout-path 
REQ  Application-comments 

SPECIFIC. 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC,  AND_GENERIC; 
PERM  Transparency 
PERM  Colour 
PERM  Border 


} 


{OBJECT_CLASS_ID_OF(LabelComponent)} 

{OBJECT_CLASS_ID_OF(LabelComponent)} 

{SUB_ID_OF(TableLabelContent)+}, 

{ANY_VALUE}. 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_ VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}, 
{REQ  #constraint-name  {"39"}. 
PERM  #external-data  {ANY_VALUE}} 

{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE} 


7.4.3.41  Row  Area 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates 


}. 

REQ  Position 


{$RowAreaGFS} 

{REQ  #variable-posttion  { 

PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_ VALUE}. 
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REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 

PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC_AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 

} 


PERM  #alignment  {ANY_VALUE}, 
PERM  #till-order  {  normal-order  }}}, 

{REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #fixed-dimension  {ANY_VALUE}}}, 

{'270-degrees'}, 

{REQ  #constraint-name  {"40"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(RowArea)} 

{OBJECT_CLASS_ID_OF(RowArea)} 

{SUBJD_OF(Cell)+, 
SUB_ID_OF(SubRowGroup)), 
{ANY_VALUE}, 
{REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #1ixed-dimension  {ANY_VALUE}}}, 
{REQ  #constraint-name  {"40"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 


7.4.3.42  Cell 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

REQ  Position 


REQ  Dimensions 


{REQ  #fixed-position  { 

REQ  #horizontal-position  {ANY_VALUE}, 
REQ  #venical-position  {ANY_VALUE}}}, 

{REQ  #horizontal-dimension 

{REQ  #tixed-dimension  {ANY_VALUE}}, 

REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #1ixed-dimension  {ANY_VALUE} 

|REQ  #maximum-size  {'applies'}}}, 


PERM  Layout-path  {'270-degrees'}, 
REQ   Permitted-categories  {ANY_STRING...}, 

-  category  name  for  tables  should  be  specified  - 
REQ  Application-comments  {REQ  #constraint-name  {"41"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 
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$FPDA: 
}. 


PERM  Object-class 
REQ  Object-class 


REG  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Imaging-order 
PERM  Application-comments 

SPECIFIC.  AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 


{OBJECT_CLASSJD_OF(Cell)} 

{OBJECT_CLASS_l  D_OF(Cell)} 

{SUB_ID_OF(SpecificBlock)}. 

{ANY_VALUE}, 

{REQ  #horizontal-dimension 

{REG  #fixed-dimension  {ANY_VALUE}}, 
REG  #vertical-dimension 

{REG  #fixed-dimension  {ANY_VALUE}}}. 
{ANY_VALUE}. 

{REG  #constraint-name  {"41"}, 
PERM  #extemal-data  {ANY_VALUE}} 

{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE} 


7.4.3.43  SubRowGroup 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REG  Generator-for-subordinates  {$SubRowGroupGFS) 


}. 

REG  Position 


REG  Dimensions 


PERM  Layout-path 

REG  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REG  Object-class 

}. 

REG  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Application-comments 


{REG  #fixed-position  { 

REG  #horlzontal-position  {ANY_ VALUE}. 
REG  #venical-position  {ANY_VALUE}}}. 

{REG  #horizontal-dimension 

{REG  #tixed-dimension  {ANY_VALUE}}. 

REG  #vertical-dimension 

{REG  #rule-b  {ANY_VALUE} 

|REG  #fixed-dimension  {ANY_VALUE} 

|REG  #maximum-size  {'applies'}}}, 

{•270-degrees'}. 

{REG  #constraint-name  {"42"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(SubRowGroup)} 

{OBJECT_CLASS_ID_OF(SubRowGroup}} 

{SUB_ID_OF(SubRow)+}. 

{ANY_VALUE}. 

{REG  #hori2ontal-dimension 

{REG  #fixed-dimension  {ANY_VALUE}}. 
REG  #vertical-dimension 

{REG  #fixed-dimension  {ANY_VALUE}}}. 
{REG  #constraint-name  {"42"}. 
PERM  #extemal-data  {ANY_VALUE}} 
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SPECIFIC_AND_GENERIC: 
PERM  Transparency 
PERM  Cotour 
PERM  Border 

} 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 


7.4.3.44  SubRow 


:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {$SubRowGFS} 


REQ  Position 


REQ  Dimensions 


PERM  Layout-path 

REQ  Application-comments 

SPECIFIC; 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 
PERM  Position 
PERM  Dimensions 


PERM  Application-comments 

SPECIFIC.  AND_GENERIC: 
PERM  Transparency 
PERM  Colour 
PERM  Border 

} 


{REQ  #variable-position  { 

PERM  #offset  {ANY_VALUE}. 

PERM  #separation  {ANY_VALUE}. 

PERM  #alignment  {ANY_VALUE}. 

PERM  #fill-order  {'normal-order'}}}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE} 

|REQ  #fixed-dimension  {ANY_VALUE} 

IREQ  #maximum-si2e  {'applies'}}}. 
{■270-degrees'}, 

{REQ  #constraint-name  {"43"}. 
PERM  #extemal-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(SubRow)} 

{OBJECT_CLASS_ID_OF{SubRow)} 

{SUB_ID_OF(Cell)+}. 

{ANY_VALUE}, 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dlmension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{REQ  #constraint-name  {"43"}, 
PERM  #extemal-data  {ANY_VALUE}} 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 


7.4.3.45  TabieLabelContent 


:ANY-FRAME-VARIABLE  { 
GENERIC: 
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CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Logical-source 
REQ  Position 


REQ  Dimensions 


PERM  Layout-path 


REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 


$FPDA: 


REQ  Object-class 


REQ  Subordinates 

PERM  Application-comments 


{OBJECT_CLASSJD_OF(CommonContent)}, 
{REQ  #tixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}. 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 

|REQ  #nfiaximum-si2e  {'applies'}}}. 

{'270-degrees'} 

{REQ  #constraint-name  {"44"}. 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF 

(TableLabelContent)} 

{OBJECT_CLASS_ID_OF 

(TableLabelContent)} 

{SUB_ID_OF(SpeciticBlock)+}. 
{REQ  #constraint-name  {"44"}. 
PERM  #extemal-data  {ANY_ VALUE}} 


7.4.3.46  FormEntryArea 

:ANY-FRAME-VARIABLE  { 
GENERIC: 

CASE  $DAC  OF  { 
$PDA-FPDA: 

REQ  Position 


REQ  Dimensions 

PERM  Layout-path 

REQ  Application-comments 

SPECIFIC: 

CASE  $DAC  OF  { 
$FDA: 

PERM  Object-class 

$FPDA: 

REQ  Object-class 

}. 

REQ  Subordinates 


{REQ  #fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}. 
REQ  #vertical-position  {ANY_VALUE}}}. 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}. 
REQ  #verlical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE}}}. 
{'270-degrees'} 

{REQ  #constraint-name  ("45"}. 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF(FormEntryArea)} 
{OBJECT_CLASS_ID_OF(FormEntryArea)} 
{SUB_ID_OF(SpecificBlock)}. 
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PERM  Application-comments  {REQ  #constraint-name  {"45"}, 

I  PERM  #extemal-data  {ANY_VALUE}} 
I  SPECIFIC_AND_GENERIC: 

PERM  Permitted-categories  {ANY_STRING  } 

1  } 


7.5  Layout  style  constituent  constraints 


7.5.1  ly/lacro  definitions 

DEFINE(SameLayoutObject." 

REQ  {REQ  #logical-object  {<object-id-expr>::=PREC-OBJ(CURR-OBJ);} 

I  REQ  #logical-obj8ct  {  null  }}. 
PERM  #layout-object  {'page'  --  to  layout  object  type  - 

I  ANY_STRING  --  to  layout  category  -- 

I  OBJECT_CLASS_l D_OF(Colu mn Fixed) 
I  OBJECT_CLASS_ID_OF(ColumnVariable) 
I  OBJECT_CLASS_ID_OF(CompositeColumnFixed) 
I  OBJECT_CLASSJD_OF(CompositeColumnVariable)} 

") 


7.5.2  Factor  constraints 

FACTOR  ANY-LAYOUT-STYLE 
{ 

REQ     Layout-style-identifier  {ANY_VALUE}, 

PERM   User-visible-name  {ANY_STRING}. 

j   PERM   User-readable-comments  {ANY_STRING} 

'  } 


7.5.3  Constituent  constraints 


7.5.3.1  LStylel 

:ANY-LAYOUT-STYLE  { 

--  This  layout  style  is  only  applicable  to  composite  logical  constituent  constraints  including  the  Passage, 
j   NumberedSegment,  Title.  Caption.  Paragraph,  Phrase,  Footnote.  Figure,  Reference,  Description, 
NumberedList,  UnNumberedList.  DefinitionList.  Listltem,  ListTerm  - 

CASE  $GLAS  0F{ 
SCOMPLETE: 


PERM 

Indivisibility 

{ANY  VALUE}, 

PERM 

Layout-object-class 

{ANY  VALUE}. 

PERM 

New-layout-object 

{ANY_VALUE}. 

PERM 

Same-layout-object 

{$SameLayoutObject}, 

PERM 

Synchronization 

{ANY_VALUE} 

VOID: 

PERM 

Indivisibility 

{ANY_STRING  -to  layout  category- 
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PERM  New-layout-object 


PERM  Same-layout-object 


}} 


PERM  Synchronization 


I  page'     -to  layout  object  type- 
I'nuir}. 

{ANY_STRiNG  -to  layout  category- 
I'page*     -to  layout  object  type- 
I'nuir). 

REQ  {REQ  #logical-object 

{<object-id-expr>::=PREC-OBJ(CURR-OBJ);} 
I  REQ  #logical-object  {'null'}}, 
PERM  #layout-object 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type--} 

}. 

{ANY_VALUE} 


7.5.3.2  LStyle2 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  only  applicable  to  the  constituent  constraints  Number  and  BodyText 


CASE  $GLAS  0F{ 
ICOMPLETE: 
PERM  Block-alignment 
Concatenation 
Indivisibility 


PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
VOID. 
PERM 
PERM 
PERM 


PERM 
PERM 


PERM 
PERM 


Layout-category 
Layout -object-class 
New-layout -object 
Offset 

Same-layout-object 

Separation 

Synchronization 

Block-alignment 

Concatenatk>n 

Indivisibility 


Layout-category 
New-layout-object 


Offset 

Same-layout-object 


PERM 
PERM 


Separation 
Synchronization 


{ANY_VALUE}. 

{ANY_VALUE}, 

{ANY_VALUE}. 

{ANY_VALUE}. 

{ANY_VALUE}. 

{ANY_VALUE). 

{ANY_VALUE}. 

{SSameLayoutObject} . 

{ANY_VALUE}, 

{ANY_VALUE} 

{ANY_VALUE), 
{ANY_VALUE}. 

{ANY_STRING  -to  layout  category- 
rpage'     -to  layout  object  type- 
rnull'}, 

{ANY_VALUE}, 

{ANY_STRING  -to  layout  category- 
I'page*     -to  layout  object  type- 
Inull}. 

{ANY_VALUE}, 
REQ  {REQ  #logical-object 

{<object-id-expr>::=PREC-OBJ(CURR-OBJ);} 
I  REQ  #logical-object  {  null  }}. 
PERM  #layout-object 

{ANY_STRING  -to  layout  category- 
I'page"     -to  layout  object  type--} 

}. 

{ANY_VALUE}, 
{ANY_VALUE} 
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}} 


7.5.3.3  LStyle3 

;ANY-LAYOUT-STYLE{ 

--  This  layout  style  is  used  only  for  the  constituent  constraints  CommonText.  PageNumber. 
TableNumber.  Currentlnstance,  CommonNumber  and  CommonReference  -- 

PERM  Block-alignment  {ANY_VALUE}. 

PERM  Concatenation  {ANY_VALUE}, 

PERM  Offset  {ANY_VALUE}, 

PERM  Separation  {ANY_VALUE} 
} 


7.5.3.4  LStyle4 

-  This  layout  style  is  not  used  -- 


7.5.3.5  LStyleS 

:ANY-LAYOUT-STYLE  { 

--  This  layout  style  is  used  only  for  the  constituent  constraints  BodyRaster  and  BodyGeometric 


CASE  $GLAS  0F{ 
SCOMPLETE: 
PERM  Block-alignment 
Layout-category 
Layout-object-class 
New-layout-object 
Offset 

Same-layout-object 
Separation 
Synchronization 


PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
VOID; 
PERM 
PERM 
PERM 


PERM 
PERM 


Block-alignment 
Layout-category 
New-layout-object 


Offset 

Same-layout-object 


PERM 
PERM 


Separation 
Synchronization 


{ANY_VALUE}, 

{ANY_VALUE}. 

{ANY_VALUE}, 

{ANY_VALUE}, 

{ANY_VALUE}. 

{SSameLayoutObject} , 

{ANY_VALUE}, 

{ANY_VALUE} 

{ANY_VALUE}, 
{ANY_VALUE}. 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type- 
I'nuir}, 

{ANY_VALUE}. 
REG  {REQ  #logical-object 

{<object-id-expr>:;=PREC-OBJ(CURR-OBJ);} 
I  REQ  #logical-object  {'null'}}. 
PERM  #layout-object 

{ANY_STRING  -to  layout  category- 
I'page"     -to  layout  object  type-) 

}. 

{ANY_VALUE}. 
{ANY_VALUE} 
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7.5.3.6  LStylee 


:ANY-LAYOUT-STYLE  { 


--  This  layout  style  is  used  only  for  the  constituent  constraint  FootnoteText 


CASE  $GLAS  0F{ 
$COMPLETE: 


PERM 
PERM 
PERM 
REQ 
PERM 
PERM 
VOID: 
PERM 


PERM 

PERM 

REQ 

PERM 

PERM 


Indivisibility 

Block-alignment 

Concatenation 

Layout-category 

Offset 

Separation 

Indivisibility 


Block-alignment 

Concatenation 

Layout-category 

Offset 

Separation 


{ANY_VALUE}. 

{ANY_VALUE). 

{ANY_VALUE}. 

{$FOOTNOTEC  ATEGOR  Y} . 

{ANY_VALUE}. 

{ANY_VALUE} 

{ANY_STRING  -to  layout  category- 
I  page'     -to  layout  object  type- 
I'nuir}, 

{ANY_VALUE}. 

{ANY_VALUE}. 

{SFOOTNOTECATEGORY}. 

{ANY_VALUE}. 

{ANY_VALUE} 


7.5.3.7  LStyle7 

-  This  layout  style  is  not  used.  - 

7.5.3.8  LStyled 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraints  CommonRaster  and  CommonGeometric 


PERM  Block-alignment 

PERM  Offset 

PERM  Separation 
} 


{ANY_VALUE}. 
{ANY_VALUE}. 
{ANY_VALUE} 


7.5.3.9  LStyle9 
:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  only  applicable  to  the  constituent  constraint  FootnoteNumber 


PERM  Block-alignment 
REQ  Layout-category 


{ANY_VALUE}. 
{$FOOTNOTECATEGORY). 
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PERM  Offset 
PERM  Separation 

) 


{ANY_VALUE}. 
{ANY_VALUE} 


7.5.3.10  LStylelO 

:ANY-LAYOUT-STYLE  { 

--  This  layout  style  is  only  applicable  to  the  constituent  constraints  Footnote  Reference  and 
ReferencedContent  -- 


CASE  $GLAS  0F{ 

SCOMPLETE: 

PERM  Block-alignment 

PERM  Concatenation 

PERM  Indivisibility 

PERM  Layout-category 

PERM  Offset 

PERM  Same-layout-object 

PERM  Separation 

VOID: 

PERM  Block-alignment 

PERM  Concatenation 

PERM  Indivisibility 


PERM  Layout-category 

PERM  Offset 

PERM  Same-layout-object 


PERM  Separation 


{ANY_VALUE}, 

{ANY_VALUE}. 

{ANY_VALUE}. 

{ANY_VALUE}. 

{ANY_VALUE}, 

{$SameLayoutObject}. 

{ANY_VALUE} 

{ANY_VALUE}. 
{ANY_VALUE}. 

jANY_STRING  -to  layout  category - 
I'page'     -to  layout  object  type- 
rnull'}, 

{ANY_VALUE}, 
{ANY_VALUE}. 
REQ  {REQ  #logical-object 

{<object-id-expr>;:=PREC-OBJ(CURR-OBJ);} 
I  REQ  #logical-object  {  null  }}, 
PERM  #layout-object 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type--} 

}. 

{ANY_VALUE} 


7.5.3.11  LStylell 

:ANY-LAYOUT-STYLE  { 

"  This  layout  style  is  used  only  for  the  constituent  constraint  FootnoteBody  - 

CASE  $GLAS  0F{ 
SCOMPLETE: 

PERM        Indivisibility  {ANY_VALUE}. 

PERM       Same-layout-object  {SSameLayoutObject}. 

PERM        Synchronization  {ANY_VALUE} 
VOID: 

PERM       Indivisibility  {ANY_STRING  -to  layout  category- 

I  page     -to  layout  object  type- 
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PERM  Same-layout-object 


}} 


PERM  Synchronization 


rnull}. 

REQ  {REQ  #logical-object 

{<object-id-expr>::=PREC-OBJ(CURR-OBJ);} 
I  REQ  #logical-object  {'null'}}. 
PERM  #layout -object 

{ANY_STRING  -to  layout  category- 
I  page"     -to  layout  object  type--} 

}. 

{ANY_VALUE} 


7.5.3.12  LStyle12 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraint  Artwor1< 


CASE  $GLAS  0F{ 
SCOMPLETE: 
PERM  Indivisibility 


PERM 
PERM 


PERM 

VOID: 
PERM 


Layout-object-class 
New-layout-object 


Synchronization 
Indivisibility 


}} 


PERM  New-layout-object 


PERM  Synchronization 


{ANY_STRING  -  to  layout  category  - 
I'page'  -  to  layout  object  type  - 

Inuil'}, 

{OBJECT_CLASSJD_OF(CompositeArtwork)}. 

{OBJECT_CLASS_ID_OF(Compos(teColumnFixed) 

|OBJECT_CLASS_ID_OF(CompositeColumnVariable) 

-  to  layout  object  class  - 
|ANY_STRING  -  to  layout  category  - 
I'page"  -  to  layout  object  type  - 

I'nuir}. 

{ANY_VALUE} 

{ANY_STRING  -to  layout  category- 
I'page'     -to  layout  object  type- 
I'null'}. 

{ANY_STRING  -to  layout  category- 
I  page'     -to  layout  object  type- 
rnull}. 

{ANY_VALUE} 


7.5.3.13  LStyleTI 
ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraint  Form 


REQ  Layout-object-class 
} 


{OBJECT_CLASS_ID_OF{FormArea)} 
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7.5.3.14  LStyleT2 


:ANY-LAYOUT-STYLE  { 

-  This  layout  style  Is  used  only  for  the  constituent  constraint  EntryElement  -- 

--  In  the  case  of  Form,  the  following  attribute  must  be  specified.  - 
REQ  Layout-object-class  {OBJECT_CLASS_ID_OF(FormEntryArea)} 

I 

»  In  the  case  of  Table,  both  of  the  following  attributes  must  be  specified.  - 
REQ  New-layout-object  {OBJECT_CLASS_ID_OF(Cell)  -  to  layout  object  class 

|ANY_STRING  -  to  layout  category  -}. 

REQ  Indivisibility  {OBJECT_CLASS_ID_OF{Cell)  -  to  layout  object  class 

|ANY_STRING  -  to  layout  category  - 

} 


7.5.3.15  LStyleT3 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraint  EntryGroup  -- 

REQ  Layout-object-class  {OBJECT_CLASS_ID_OF(EntryGroupArea)} 
} 


7.5.3.16  LStyleT4 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for 

REQ  New-layout-object 
PERM  Indivisibility 


PERM  Same-layout-object 

} 


7.5.3.17  LStyleT5 

:ANY-LAYOUT-STYLE  { 
"  This  layout  style  is  used  only  for  the  constituent  constraint  Row  -- 

REQ    New-layout-object  {OBJECT_CLASSJD_OF(RowArea)}. 

PERM  Indivisibility  {OBJECT_CLASSJD_OF(RowArea) 

"  to  layout  object  class 
|ANY_STRING  -  to  layout  category  - 
I'page'  ~  to  layout  object  type  -- 

Inull} 


a  logical  object  class  of  the  constituent  constraint  Table 

{OBJECT_CLASSJD_OF(TableArea)}. 
{OBJECT_CLASS_ID_OF(TableArea) 

-  to  layout  object  class  ~ 
|ANY_STRING  -  to  layout  category 
I  page'  -  to  layout  object  type  - 

I  'null'  }. 

{$SameLayoutObject} 
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} 

7.5.3.18  LStyleT6 

:ANY-LAYOUT-STYLE  {  . 

--  This  layout  style  is  used  only  for  the  constituent  constraint  TableComponent  -- 
REQ    Layout-object-class  {OBJECT_CLASS_ID_OF(SubRowGroup)} 


7.5.3.19  LStyleT7 

:ANY-LAYOUT-STYLE  { 

"  This  layout  style  is  used  only  for  the  constituent  constraint  RowComponent 


REQ  New-layout-object 
PERM  Indivisibility 


} 


{OBJECT_CLASS_ID_OF(SubRow)}. 
{OBJECT_CLASS_ID_OF(SubRow) 

-  to  layout  object  class  - 
|ANY_STRING  -  to  layout  category  - 
rnull} 


7.5.3.20  LStyleT8 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  a  logical  object  of  the  constituent  constraint  Table 


PERM  Indivisibility 


PERM  Same-layout-object 


{OBJECT_CLASS_ID_OF(TableArea) 

-  to  layout  object  class 
|ANY_STRING    to  layout  category  -- 
I'page"  --  to  layout  object  type  - 

Inuir}. 

{SSameLayoutObject} 


7.5.3.21  LStyleTS 

:ANY-LAYOUT-STYLE  { 

-  This  layout  style  is  used  only  for  the  constituent  constraints  EntryText.EntryRaster.EntryGeometric. 


PERM  Block-alignment 

PERM  Layout-category 

PERM  Offset 

} 


{ANY_VALUE), 
{ANY_VALUE}, 
{ANY_VALUE} 
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7.6  Presentation  style  constituent  constraints 

7.6.1  Macro  definitions 

-  No  macro  definitions  are  applicable  to  this  subclause. 

7.6.2  Factor  constraints 

FACTOR  ANY-PRESENTATION-STYLE 


{ 

REQ  Presentation-style-identifier 

PERM  User-readable-comments 

PERM  User-visible-name 

PERM  Border 

PERM  Colour 

PERM  Transparency 

} 


{ANY_VALUE}. 

{ANY_STRING}. 

{ANY_STRING}. 

{ANY_VALUE}, 

{ANY_VALUE}, 

{ANY_VALUE} 


7.6.3  Constituent  constraints 


7.6.3.1  PStylel 


:ANY-PRESENTATION-STYLE  { 


This  style  is  used  for  the  constituent  constraints  BodyText,  Number.  FootnoteNumtjer, 
FootnoteReference.  FootnoteText,  Entry  Text,  ReferencedContent,  GenericBlock  and 
SpecificBlock.  - 


PERM  Presentation-attributes  { 
PERM  #character-attributes  { 


PERM 

#alignment 

{ANY  VALUE}, 

PERM 

#character-fonts 

{ANY  VALUE}, 

PERM 

#character-orientation 

{ANY  VALUE}. 

PERM 

#character-path 

{ANY  VALUE}. 

PERM 

#character-spacing 

{ANY  VALUE}, 

PERM 

#code-extension-annou  ncers 

{$CDEXTEN}, 

PERM 

#first-line-offset 

{ANY  VALUE}. 

PERM 

#graphic-character-sets 

{$PERMIT-GRCHAR}. 

PERM 

#graphic-character-subreperloire  {ANY_VALUE}, 

PERM 

#graphic-rendition 

{$GRAPHICRENDITIONS}. 

PERM 

#indentation 

{ANY  VALUE}. 

PERM 

#itemization 

{ANY  VALUE}. 

PERM 

#kerning-offset 

{ANY  VALUE}, 

PERM 

#line-layout-table 

{ANY  VALUE}. 

PERM 

#line-progression 

{ANY  VALUE}. 

PERM 

#line-spacing 

{ANY  VALUE}, 

PERM 

#orphan-si2e 

{ANY  VALUE}, 

PERM 

#painwise-kerning 

{ANY_VALUE}, 

PERM 

#proponional-line-spacing 

{ANY  VALUE}. 

PERM 

#widow-size 

{ANY  VALUE}. 
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PERM  #initial-offset  {ANY_VALUE}. 

PERM  #tormatting-indicator  {ANY.VALUE} 

} 

}} 


7.6.3.2  PStyle2 

:ANY-PRESENTATION-STYLE  { 

This  style  is  used  for  the  constituent  constraints  BodyGeometric,  ComnionGeometric. 
EntryGeometric,  GenericBlock  and  SpecificBlock.  -- 

PERM  Presentation-attributes  { 

PERM  #geometric-graphics-attributes  {ANY_VALUE}} 

} 


7.6.3.3  PStyle3 

:ANY-PRESENTATION-STYLE  { 

This  style  is  used  tor  the  constituent  constraints  BodyRaster.  CommonRaster.  EntryRaster, 
GenericBlock  and  SpecificBlock.  -- 


PERM  Presentation-attributes  { 
PERM  #raster-graphics-attributes  { 

PERM  #pel-path  {ANY_VALUE}. 

PERM  #line-progression  {ANY_VALUE}. 

PERM  #pel-spacing  {ANY_VALUE}. 

PERM  #spacing-ratio  {ANY_VALUE}. 

PERM  #clipping  {ANY_VALUE}, 

PERM  #image-dimensions  {ANY_VALUE} 


}} 


} 


7.6.3.4  PStyle4 

:ANY-PRESENTATION-STYLE  { 

This  style  is  used  for  the  constituent  constraints  CommonText.  PageNumber,  TableNumber. 
CommonReference,  Currentlnstance  and  SpecificBlock. 


PERM  Presentation-attributes  { 
PERM  #character-attributes  { 
PERM  #alignment 
PERM  #character-fonts 
PERM  #character-orientation 
PERM  #character-path 
PERM  #character-spacing 
PERM  #code-extension-announcers 
PERM  #first-line-offset 
PERM  #graphic-character-sets 
PERM  #graphic-character-subreperto 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE), 
{ANY_VALUE}. 
{SCDEXTEN}. 
{ANY_VALUE). 
{$PERMIT-GRCHAR}. 
Ire  {ANY_VALUE}. 
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PERM 

#graphic-rendition 

{$GRAPHICRENDITIONS} 

PERM 

#indentation 

{ANY  VALUE}, 

PERM 

#jtemizatjon 

{ANY  VALUE), 

PERM 

#kerning-offset 

{ANY  VALUE}. 

PERM 

#line-layout-table 

{ANY  VALUE}. 

PERM 

#line-progression 

{ANY  VALUE}. 

PERM 

#line-spacing 

{ANY  VALUE}. 

PERM 

#pajrwise-kerning 

{ANY  VALUE}. 

PERM 

#proportional-line-spacing 

{ANY  VALUE}. 

PERM 

#initial-offset 

{ANY  VALUE}. 

PERM 

#formatting-indicator 

{ANY  VALUE} 

} 

}} 


7.7  Content  portion  constituent  constraints 


7.7.1  Macro  definitions 

DEFINE(T6.  "ASN.1  {2837  0}") 

DEFINE(T41D.  "ASN.I  {2837  1}") 

DEFINE{T42D.  "ASN.I  {2837  2}") 

DEFINE(Bitmap.         "ASN.I  {2837  3}") 


7.7.2  Factor  constraints 

FACTOR  ANY-CONTENT  { 

CASE  $DAC  OF  { 
$FDA  : 

REQ  Content-identifier-layout  {ANY_VALUE} 

$PDA  : 

REQ  Content-identifier-togical  {ANY_VALUE} 

~  This  attribute  is  specified,  if  the  content  portion  is  associated  with 
a  basic  logical  object  or  a  basic  logical  object  class.  ~ 
|REQ  Content-identifier-layout  {ANY_VALUE} 

-  This  attribute  is  specified,  if  the  content  portion  is  associated  with 
a  basic  layout  object  class.  ~ 

$FPDA  : 

REQ  Content-identifier-layout  {ANY_VALUE}. 
REQ  Content-identifier-logical  {ANY_VALUE} 

~  Both  attributes  are  specified,  if  the  content  portion  is  associated  with 
a  basic  logical  object  and  a  basic  layout  object.  - 
I  REQ  Content-identifier-layout  {ANY_VALUE} 

-  This  attribute  is  specified,  if  the  content  portion  is  associated  with 
a  basic  layout  object  class.  - 

|REQ  Content-identifier-logical  {ANY_VALUE} 

~  This  attribute  is  specified,  if  the  content  portion  is  associated  with 
a  basic  logical  object  class.  - 
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). 

PERM  Alternative-representation  {ANY_STRING} 
} 


7.7.3  Constituent  constraints 


7.7.3.1  Character-content-portion 


:ANY-CONTENT  { 
PERM  Type-of-coding 
PERM  Content-information 


{ASN.1{2  8  3  6  0}}. 
{CHARACTER 


Shared  Control  Functions  -- 
#CR 
|#GCC 
I  #IGS 
I  #LF 
I  #PLD 
|#PLU 
I  #SCS 
I  #SGR 
I  #SHS 
I  #SLS 
I  #SRS 
I  #STAB 
I  #SUB 
I  #SVS 
I  #VPB 
I  #VPR 

Layout  Control  Functions  -- 
I  #HPB 
I  #HPR 
I  #JFY 
I #SACS 
|#SRCS 
I  #SSW 

Logical  Control  Functions  -- 
I  #BPH 
I  #NBH 
I  #PTX 

Delimiter  Functions  - 
I  #SOS 
I  #ST 

Space  - 
I  #SP 


{ANY_VALUE} 
{ANY_VALUE} 


{ANY_VALUE} 

{SGRAPHICRENDITIONS} 

{ANY_VALUE} 

{ANY_VALUE} 

{ANY_VALUE} 

{ANY_VALUE} 

{ANY_VALUE} 
{ANY_VALUE} 
{ANY_VALUE} 


{ANY_VALUE} 
{ANY_VALUE} 
{0} 

{ANY_VALUE} 
{ANY_VALUE} 
{ANY_VALUE} 


{ANY_VALUE} 


Code  extension  control  functions 
I  #LSO 
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|#LS1R 
I  #LS2R 
I  #LS3R 
I  #SS2 
|#SS3 

I  #ESC  {SDEG-CORE-GO} 
I  #ESC  {$DEG-646-G0} 
I  #ESC  {$DEG-ANY-G1} 
I  #ESC  {$DEG-ANY-G2} 
I  #ESC  {$DEG-ANY-G3} 
I  #ESC  {$DEG-EMPTY-G1} 
}•••} 

} 


7.7.3.2  Raster-graphics-content-porlion 


{$T6|$T41  D|$T42D|$Bitmap}. 
{ 

{ANY_VALUE}. 

{>0}. 
{>=0} 

{RASTER} 


:ANY-CONTENT  { 

PERM  Type-of-coding 

PERM  Coding-attributes 
PERM  #compression 
PERM  #numl5er-of-lines 
REQ  #number-of-pels-per-line 
}. 

PERM  Content-information 
} 


7.7.3.3  Geometric-graphics-content-portion 

lANY-CONTENT  { 

PERM  Type-of-coding  {ASN.1  {28380}}. 

PERM  Content-information  {GEOMETRIC} 

I  } 


8  Interchange  format 

For  conformance  to  tfiis  profile,  the  intercfiange  format  class  A  shall  be  used  when  applying  ODIF.  and  the 
interchange  format  SDIF  shall  be  used  when  applying  ODL  in  conjunction  with  SDIF. 

NOTE  30  -  interchange  format  SDIF  applies  to  the  ISP  only. 

! 

I  8.1  Interchange  format  class  A 


8.1.1  Interchange  format 

The  value  of  the  document  profile  attribute  "interchange  format"  for  this  interchange  format  is  "if-a".  This 
form  of  ODIF  is  defined  in  [CCITT  Recomendation  T.415  |  ISO  8613-5]. 
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8.1.2  DAP  identifier 


The  value  for  the  document  profile  attribute  "document  application  profile"  for  this  interchange  format  is 
represented  by  the  following  object  identifier. 

ASN.1  {  2  8  4  0  36  0  } 

8.1.3  Encoding  of  application  comments 

The  encoding  of  the  attribute  "application  comments"  is  defined  in  this  encoding  as  an  octet  string  as 
specified  in  (CCITT  Recommendation  T.415 1  ISO  8613-5].  This  document  application  profile  requires  that 
the  encoding  within  that  octet  string  be  in  accordance  with  the  ASN.1  syntax  specified  in  the  following 
module  definition: 

FOD_DAPSpecification 
DEFINITIONS  :;=  BEGIN 
EXPORTS  Appl-Comm-Encoding; 

Appl-Comm- Encoding  ;:=    SEQUENCE  { 

constraint-name  [0]  IMPLICIT  PrintableString  OPTIONAL, 

external-data  (1]  IMPLICIT  OCTETSTRING  OPTIONAL  } 

,  END 


8.1.4  Data  lengths 

The  maximum  length  of  data  values  of  the  type  OCTET  STRING,  as  defined  in  [ISO  8824  |  CCITT 
Recommendation  X.208].  in  data  streams  which  may  be  encoded  in  accordance  with  this  DAP  is  32767 
octets.  II  it  is  required  to  encode  contents  octets  of  greater  length  than  this,  constructed  type  encoding 
shall  t>e  used.  That  is,  data  values  greater  than  32767  in  length  shall  be  split  into  a  sequence  of  strings 
shorter  than  32767,  each  of  which  is  encoded  using  a  primitive  type. 


8.2  Interchange  format  SDIF 

NOTE  31  -  The  subclause  8.2  applies  to  the  ISP  only. 


8.2.1  Interchange  format 

The  document  profile  attriljute  "interchange  format"  does  not  apply  for  this  interchange  format.  This  form 
of  the  interchange  format  is  defined  in  Annex  E  of  (CCITT  Recommendation  T.415  |  ISO  8613-5).  (CCITT 
Recommendations  T.416.  T.417.  and  T.418  |  ISO  8613-6,  -7  and  -8)  contain  additional  specifications  for 
this  interchange  format. 


8.2.2  DAP  identifier 

The  value  for  the  attribute  "document  application  profile"  for  this  interchange  format  is  represented  by  the 
following  object  identifier. 

ASN.1  {  1  0  11182  0  36  0  } 

NOTE  32  -  There  is  no  requirement  to  include  a  part  number  arc  within  the  object  identifier  for  the  DAP. 
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8.2.3  Encoding  of  application  comments 


The  encoding  of  the  attribute  "application  comments"  is  defined  in  data  stream  confonning  to  this  profile 
with  this  encoding  with  the  following  DTD  definition: 

<!--  Public  document  type  definition.  Typical  invocation: 

<!DOCTYPE  fodapc  PUBLIC  "ISO/IEC  11182-1  :  1992//DTD 

Application  Comments//EN"  ( "  ]> 


For  example,  a  typical  SUBDOC  for  representing  the  "application  comments"  of  a  Paragraph  then  would 
look  like: 

<!DOCTYPE  fodapc  PUBLIC  "ISO/IEC  11182-1  : 1992//DTD  Application  Comments//EN"> 
<fodapc  consname=6> 

If  the  optionality  of  the  attribute  "fodapc"  is  specified  in  an  earlier  portion  of  the  DTD.  the  invocation  may 
be  minimized  further  because  the  tag  is  not  needed  when  "application  comments"  are  not  included  as  is 
the  case  here. 

The  content  of  external  data  appearing  inline  is  restricted  to  parsable  data.  Referenced  extemal  data  need 
not  be  parsable. 


> 


<!ELElylENT  fodapc 
<!ATTLIST  fodapc 
<!ELEMENT  externi 
<!ATTLIST  externi 


-  0  (externl?)> 
consname  CDATA  #II^PLIED> 

-  0  {#PCDATA)> 

loc       ENTITY  #CONREF> 
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Annex  A 
Amendments  and  corrigenda 


(This  annex  forms  an  integral  part  of  this  specification.) 
A.1  Amendments 

A.1 .1  Amendments  to  the  base  standard 

The  amendments  applicable  to  this  CCITT  Recommendation  |  ISP  includes  the  ISO  8613  -  Amendment 
1: 1990.  This  amendment  includes  text  to  be  included  in  ISO  8613-1  as  the  following  annexes: 

—  Annex  E:  Use  of  ISO/IEC  10021  (MOTIS)  to  interchange  documents  conforming  to  ISO 

8613; 

—  Annex  F:  Document  Application  Profile  proforma  and  notation; 

—  Annex  G:  Conformance  testing  methodology; 

—  Annex  H:  Recording  of  documents  conforming  to  ISO  8613  on  flexible  disk  cartridges 
conforming  to  ISO  9293. 

In  addition,  this  amendment  addresses  the  inclusion  of  the  ISO  8613  Technical  Corrigenda  1. 
This  ISP  does  not  include  the  following  features  of  the  amendment: 

—  addendum  on  security; 

—  addendum  on  styles; 

—  addendum  on  alternative  representation; 

—  addendum  on  colour; 

—  addendum  on  tiled  raster  graphics. 

A.1 .2  Proposed  changes  to  standards  due  to  defects 

Proposed  Technical  Corrigendum  No.  44  to  (ISO  8613 1  T.410  recommendations]  dated  15  December  1991 
assumed  to  be  ratified  by  ISO. 
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A.2  Corrigenda 

A.2.1  Corrigenda  to  tlie  CCITT  Recommendation  |  ISP 
There  is  no  corrigendum  specific  to  this  CCITT  Recommendation  |  ISP. 
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Annex  B 


Recommendations 


(This  annex  does  not  form  an  integral  part  of  this  specification.) 


B.I  Transfer  methods  for  ODA 


B.1.1  Conveyance  of  ODA  over  CCITT  X.400-1 984 

This  recommendation  describes  how  ODA  body  parts  are  to  be  encoded  for  transmission  over  a  CCITT 
X.400-1 984  service. 

An  ODA  body  part  is  encoded  as  OdaBodyPart  in  the  definition  given  below: 

OdaBodyPart  ::=  SEQUENCE  {  OdaBodyPartParameters,  OdaData  } 
OdaBodyParlParameters  ::=  SET  { 
document-application-profile 

[0]  IMPLICIT  OBJECT  IDENTIFER. 
document-architecture-class 

(1]  IMPLICIT  INTEGER  { 
formatted  (0), 
processable  (1), 
formatted-processable  (2) } 
OdaData  ;:=     SEQUENCE  OF  Interchange-Data-Element 

NOTE  33  -  It  is  recommended  to  transfer  an  ODA  document  as  a  single  body  part  with  tag  12: 

Oda  [12]  IMPLICIT  OCTETSTRING 

The  content  of  the  octet  string  is  encoded  as  OdaBodyPart,  defined  above.  However,  this  is  out  of  the 
scope  of  this  profile. 


8.1 .2  Conveyance  of  ODA  over  FTAM 

This  recommendation  describes  the  FTAM  Document  Type  to  be  used  for  minimal  storage  and  transfer 
capabilities  of  ODA  data  streams.  It  is  recognized  that  enhanced  capabilities  may  at  some  point  be  added. 

When  using  FTAM  to  transfer  an  ODA  file,  the  FTAM-3.  "ISO  FTAM  Unstructured  Binary",  document  type 
shall  be  specified. 

However,  since  files  that  do  not  contain  ODA  data  streams  can  have  the  same  document  type,  it  is  left  up 
to  the  user  of  application  programs  that  remotely  access  files  using  FTAM  to  know  that  a  given  file  contains 
an  ODA  data  stream. 
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B.I  .3  Conveyance  of  ODA  over  DTAM 

This  recommendation  provides  for  information  concerning  the  interchange  of  ODA  based  documents  with 
DTAM  protocols. 

DTAM  (Document  Transfer  and  Manipulation)  is  defined  in  the  T.430-Series  of  recommendations  and  is, 
like  ODA.  an  integral  part  of  the  T.400-Series  of  CCITT  Recommendations  named  Open  Document 
Architecture,  Transfer  and  Manipulation. 

The  T.520-Series  of  recommendations  contain  Communication  Application  Profiles  (CAP). 
Recommendation  T.522  describes  the  Communication  Application  Profile  BT1  for  document  bulk  transfer. 
Recommendation  T.522  is  applicable  for  the  Office  Document  Format  Profile  (POD)  published  in  this  ISP. 

NOTE  34  -  The  use  of  BTI  within  the  end-to-end  oriented  Telematic  Services  Telefax  4  and  Teletex  is  described 
in  Recommendation  T.561,  subclause  7.1  and  Recommendation  T.562,  subclause  7.1. 


B.1.4  Conveyance  of  ODA  over  flexible  disks 

The  recommended  method  for  interchanging  ODA  documents  between  systems  by  the  exchange  of 
magnetically  recorded  Flexible  Disk  Cartridges  is  by  the  use  of  an  annex  to  (CCITT  Recommendation  T.41 1 
I  ISO  8613-1]  (to  be  published),  "Recording  of  Documents  Conforming  to  ISO  8613  on  Flexible  Cartridges 
Conforming  to  ISO  9293".  This  annex  provides  for  recording  each  ODA  document  as  a  separate  file  as 
defined  by  ISO  9293,  "Volume  and  File  Stmcture  of  Flexible  Disk  Cartridges  for  Information  Intercfiange". 

NOTE  35  -  Document  encoded  in  ODL  may  be  stored  such  that  each  SGML  ENTITY  is  recorded  in  a  separate 
file  or  in  the  case  of  an  SDIF  encoding,  the  file  may  be  stored  in  a  single  file. 


B.2  Font  reference 

The  recommended  method  for  specifying  a  font  reference  is  to  be  based  on  ISO  9541 . 

Font  sizes  from  6  to  72  points  (100  to  1200  BMU)  are  intended  to  be  supported  by  implementation 
conforming  to  this  recommendation.  All  other  values  of  font  sizes  may  additionally  be  supported,  but 
implementations  may  also  support  using  some  form  of  "fallback". 

The  minimum  font  properties  and  values  from  ISO  9541  that  are  to  be  specified  In  a  Font-Attribute-Set  are 
those  specified  by  the  following  document  application  profile  notation. 


Font-Attribute-Set 


{ 


PERM  Font-Name 
PERM  Standard-Version 
PERM  Data-source 
PERM  Design-source 
PERM  Font-Family-Name 
PERM  Posture 
PERM  Weight 
PERM  Proportionate-Width 
PERM  Glyph-Complement  { 

PERM  #lncluded-Glyph-Collections 


{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_VALUE), 
{ANY_VALUE}. 
{ANY_VALUE}, 
{'upright'  |  'italic-f onward'}, 
{'light'  I  'medium'  |  'bold  ), 
{ANY_VALUE}, 
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{ANY_VALUE}. 
PERM  #Excluded-Glyph-Collections 

{ANY_VALUE}. 

PERM  #lncluded-Glyphs  {ANY_VALUE}. 
PERM  #Excluded-Glyphs  {ANY_VALUE} 

). 

PERM  Design-Size 

PERM  Min-Size  { 

PERM  #Numerator  {100 
PERM  #Denominator  { 1 ) 


PERM  Max-Size 

PERM  #Numerator 
PERM  #Denominator 


{ANY_VALUE). 
1200}. 


{100 
{1} 


1200}. 


"  BMU  Units  equivalent  to  range  of  6. .72  point  sizes  -- 
PERM  Design-Group  { 

PERM  #Class  {ANY_VALUE}. 
PERM  #Subciass  {ANY_VALUE}. 
PERM  #Specific-Group  {ANY_VALUE} 

). 

PERM  Structure  {ANY_VALUE}. 
PERM  Writing-Modes  { 

MUL  { 

REQ  #Writing-Mode-Name 

{ANY_VALUE}. 
PERM  #Nominal-Escapement-Direction 

{ANY_VALUE}. 
PERM  #Escapement-Class 

{ANY_VALUE}. 
PERM  #Average-Escapement-X 

{ANY_VALUE}. 
PERM  #Average-Escapement-Y 

{ANY_VALUE} 
} 

) 

} 


B.3  ISO  8632  (CGM)  constraints  for  this  DAP 

It  is  recommended  that  geometric  graphics  content  information  contain  only  those  elements  listed  in  this 
portion  of  the  document,  in  addition  to  the  constraints  imposed  by  (CCITT  Recommendation  T.418  |  ISO 
8613-8].  It  is  believed  that  this  subset  of  the  CGM  is  sufficiently  implemented  to  enable  intenworking  of 
geometric  graphics  for  application  conforming  to  this  document  application  profile. 

Where  an  element  has  parameters,  recommended  constraints  on  the  values  are  given.  The  symbol' 
indicates  that  there  is  no  recommended  constraint. 

Requirements  in  ISO  8632  and  (CCITT  Recommendation  T.418  |  ISO  8613-8]  concerning  mandatory 
elements,  parameters  shall  be  fulfilled. 
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3.3.1  Delimiter  elements 

>lo-Op 

3egin  Metafile 


End  Metafile 
Begin  Picture 


legin  Picture  Body 
■nd  Picture 


An  arbitrary  sequence  of  n  octets.  Where  n=0,  1,  ..,  32767  Tfie 
sequence  of  zero  or  more  octets  is  for  padding  purposes. 
Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets. 

Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets. 


|B.3.2  Metafile  descriptor  elements 


Metafile  Version 
I  Metafile  Description 


VDC  Type 
Integer  Precision 
Real  Precision 
Index  Precision 
Colour  Precision 
Colour  Index  Precision 
Maximum  Colour  Index 
Colour  Value  Extent 
Metafile  Element  List 
Metafile  Defaults  Replacement 
Font  List 


Character  Set  List 


Character  Coding  Announcer 


1 

Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets.  The  METAFILE  DESCRIPTION  string  parameter 
will  be  used  to  include  the  sub-string  "ISO  FOD36"  to  label  the 
content  information  as  conforming  to  this  profile.  In  addition, 
generators  of  content  are  encouraged  to  append  a  sub-string  that 
identifies  the  company  and  product  that  produced  the  CGM. 

16,  32 

(0.9,23).  (1.16.16) 
16 

8,  16 
8,  16 
0..63 


All  fonts  referenced  in  the  metafile  shall  be  defined.  Font 
referencing  in  FONT  LISTS  using  ISO  9541  names  is  preferred, 
but  font  names  may  be  specified  using  proprietary  font  names. 
All  character  sets  referenced  in  the  metafile  shall  be  defined  in 
CHARACTER  SET  LIST.  Permissible  character  sets  are  the 
same  as  for  character  content  architecture. 


B.3.3  Picture  descriptor  elements 

Scaling  Mode  The  Scale  Factor  parameter  of  SCALING  MODE  element  is 

always  a  32-bit  floating  point  value,  even  when  the  REAL 
PRECISION  has  selected  fixed  point  for  other  real  numbers.  It  is 
not  apparent  in  ISO  8632  what  the  precision  of  this  floating  point 
value  is  when  fixed  point  has  been  selected.  Its  precision  shall  be 
(0,9,23). 

Colour  Selection  Mode 

Line  Width  Specification  Mode 
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Marker  Size  Specification  Mode 
Edge  Width  Specification  Mode 
VDC  Extent 
Background  Colour 


B.3.4  Control  elements 


VDC  Integer  Precision 
VDC  Real  Precision 
Auxiliary  Colour 
Transparency 
Clip  Rectangle 
Clip  Indicator 


16.  32 

(0.9.23).  (1.16.16) 
Transparent 


B.3.5  Graphical  primitive  elements 


Polyline 

Disjoint  Polyline 

Polymarker 

Text 


Restricted  Text 


Append  Text 


Polygon 
Polygon  Set 
Cell  Array 


Rectangle 
Circle 

Circular  Arc  3  Point 
Circular  Arc  3  Point  Close 
Circular  Arc  Centre 
Circular  Arc  Centre  Close 
Ellipse 
Elliptical  Arc 
Elliptical  Arc  Ctose 


The  minimum  support  for  the  length  of  point  lists  is  1024  points. 
The  minimum  support  for  the  length  of  point  lists  is  1024  points. 
The  minimum  support  for  the  length  of  point  lists  is  1024  points. 
Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets.  Format  effector  control  characters  are  disallowed 
in  the  string  parameter. 

Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets.  Format  effector  control  characters  are  disallowed 
in  the  string  parameter. 

Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up 
to  32767  octets.  Format  effector  control  characters  are  disallowed 
in  the  string  parameter. 

The  minimum  support  for  the  length  of  point  lists  is  1024  points. 
The  minimum  support  for  the  length  of  point  lists  is  1024  points. 
The  mininnum  support  for  the  length  of  colour  lists  parameter  for 
the  CELL  ARRAY  element  is  1048576.  This  supports  a  1024  x 
1024  image. 


B.3.6  Attribute  elements 

Line  Bundle  Index 

Line  Type  Negative  values  are  prohibited. 

Line  Width 
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Ij  Jne  Colour 
barker  Bundle  Index 
barker  Type 
\4arker  Size 
\^arker  Colour 
Text  Bundle  Index 
Text  Font  Index 

Character  Expansion  Factor 
Character  Spacing 
Text  Colour 
[Character  Height 
Character  Orientation 
jText  Path 
iText  Alignment 
Character  Set  Index 


H  Alternate  Character  Set  Index 


Fill  Bundle  Index 
J*|  Interior  Style 
f\  Fill  Colour 

Hatch  Index 

Pattern  Index 
h  Edge  Bundle  Index 
■  Edge  Type 

Edge  Width 
•  Edge  Colour 
,'  Edge  Visibility 

Fill  Reference  Point 
^  Pattern  Table 


Pattern  Size 

Colour  Table  Specification 


Negative  values  are  prohibited. 


All  fonts  referenced  (indexed  by  TEXT  FONT  INDEX)  in  the 
metafile  shall  be  defined  in  FONT  LIST  either  in  presentation 
parameters  of  (CCITT  Recommendation  T.410  series  |  ISO  8613] 
or  in  ISO  8632. 


All  character  sets  referenced  in  the  metafile  (indexed  by 
CHARACTER  SET  INDEX)  shall  be  defined  in  CHARACTER  SET 
LIST.  The  only  character  sets  which  may  be  designated  in  GO 
are  ISO  646  IRV  or  versions  of  ISO  646.  Other  character  sets 
shall  be  designated  in  G1.  G2  or  G3. 

All  character  sets  referenced  in  the  metafile  (indexed  by 
ALTERNATE  CHARACTER  SET  INDEX)  shall  be  defined  in 
CHARACTER  SET  LIST. 


Negative  values  are  prohibited. 
1  ..  8 


Negative  values  are  prohibited. 


The  PATTERN  TABLE  element  has  an  unspecified  effect  when  it 
appears  in  a  picture  subsequent  to  any  graphical  primitives.  The 
PATTERN  TABLE  element  shall  appear  prior  to  any  graphical 
primitive  element  to  assure  that  interpreting  systems  witfiout 
dynamic  pattern  update  can  render  the  intended  effect.  The 
minimum  support  for  the  length  of  the  Colour  Array  parameter  for 
the  PATTERN  TABLE  element  is  2048.  This  will  support  8 
patterns  of  16  x  16,  2  patterns  of  32  x  32  or  1  pattern  of  32  x  64. 
All  indexes  which  are  used  in  the  metafile  shall  be  defined. 

The  COLOUR  TABLE  element  has  an  unspecified  effect  when  it 
appears  in  a  picture  subsequent  to  any  graphical  primitives.  The 
COLOUR  TABLE  element  shall  appear  prior  to  any  graphical 
primitive  elements  to  assure  that  interpreting  systems  without 
dynamic  colour  update  can  render  the  intended  effect.  The 
minimum  support  for  the  length  of  the  Colour  List  parameter  in  the 
COLOUR  TABLE  element  is  63.  This  will  support  a  64  (0..63) 
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Aspect  Source  Flags 


entry  colour  table, 
be  defined. 


All  indexes  which  are  used  in  the  metafile  shall 

I 


B.3.7  External  elements 


Message 


The  presentation  of  message  string  may  not  be  appropriate  for  all 
applications.  No  requirement  for  formatted  presentation  of  the 
message  string  has  been  placed  on  the  Interpreter.  Only  the  No 
Action  flag  needs  to  be  supported.  Support  for  string  lengths  up 
to  254. 


Application  Data 


Support  will  be  provided  for  strings  with  a  length  up  to  254  octets, 
except  for  data  records  which  will  support  strings  with  a  length  up  f 
to  32767  octets. 


B.4  Interoperability  with  SGML  applications 


NOTE  36  -  Annex  B.4  applies  to  the  ISP  only. 


i 


The  recommended  method  for  the  exchange  of  documents  between  Standard  Generalized  Markup 
Language  (ISO  8879.  SGML)  based  systems  and  systems  based  on  this  ODA  document  application  profile  > 
is  by  means  of  exchanging  a  document  representation  conforming  to  these  agreements  in  an  encoded  form  « 
of  the  SGML  language  known  as  the  Office  Document  Language  (ODL)  ODL  Is  a  standardized  SGML  ' 
application  for  representing  documents  conforming  to  the  ODA  base  standard.  Such  a  representation  may  I 
be  converted  into  the  Office  Document  Interchange  Format  (ODIF)  supported  by  this  document  application  !! 


profile 


I 
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PART  17  -  Office  Document  Architecture 
Level  2  DAP 


December  1992  (Stable) 


Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture 
Special  Interest  Group  (ODASIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW)- 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  struckout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  17  -  Office  Document  Architecture  Level  2  DAP 

NOTE  -  Text  for  the  International  Standardized  Profile  11181-1  (FO026)  follows  this  page. 

This  Agreement  provides  a  Document  Application  Profile  which  has  been  developed  through  the 
joint  efforts  of  ODA  expert  groups  within  the: 

OSE  Implementors'  Workshop  (OIW); 

Asia-Oceania  Workshop  (AOW); 

European  Workshop  for  Open  Systems  (EWOS); 

CCITT  Study  Group  VIII. 

This  effort  was  conducted  through  meetings  of  the  Profile  Alignment  Group  for  ODA  (PAGODA)  for 
the  purpose  of  facilitating  the  intenvorking  of  applications  which  interchange  documents  based  on 
[ISO  8613  I  T.410  series  of  CCITT  Recommendations].  This  Agreement  specifies  one  of  the 
profiles  resulting  from  that  work: 

ISO/IECISP 11181-1 :  -[992,  Information  technology -Standardized  Profile  FOD36- Office  Document 
Format :  Enhanced  document  structure  -  Character,  raster  graphics  and  geomentric  graphics  content 
architectures  -  Document  Application  Profile. 


This  Agreement  accepts  the  entirety  of  the  definitions  and  provisions  of  this  ISP  as  the  agreement 
for  the  OIW  Stable  Agreements  and  the  standards  upon  which  the  specified  ISP  is  based  as 
referenced  by  the  text  of  the  ISP.  For  this  reason  the  text  of  the  ISP  is  not  reproduced  here,  but 
referenced  to  avoid  any  doubt  as  to  the  official  text  being  agreed  upon. 
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Fore«rord 


Development  of  thia  document  application  profile  has  been  done  in  liaison  with 
several  organizations.    These  include  ODA  expert  groups  within  the: 

-  Asia-Oceania  Workshop  (AOH) ; 
CCITT  study  Group  VIII; 

-  Europeem  Workshop  for  Open  systems  (EWOS); 

-  NIST  OSI  Implementors  Workshop  (OIW) . 

The  liaison  between  these  organizations  has  occurred  within  the  meetings  of  the 
Profile  Alignment  Group  for  ODA  (PAGODA) .    These  meetings  have  focused  on  the 
development  of  a  single  set  of  Internationally  aligned  ODA  document  application 
profiles. 

The  profile  defined  in  this  ISP  is  a  pairt  of  the  ODA  profile  taxonomy  defined  in 
TR  10000-2,  4.4.4.3  and  5.4.1.    This  profile  is  specific  to  the  profile 
identifier  FOD26. 

At  present,  this  ISP  consists  of  one  part: 

part  1,  Document  application  profile. 
Further  peurts  may  be  added  to  this  ISP. 
This  part  contains  three  annexes: 


annex  A  ( normative ) :  Amendments  and  corrigenda 
-         annex  B  ( informative ) :  Recommendations ; 
annex  c  (informative):  Bibliography. 
Introduction 

The  purpose  of  this  International  Standardized  Profile  (ISP)  is  to  facilitate 
the  interworking  of  applications  interchanging  documents  based  on  ISO  8613,  ODA. 
This  ISP  is  suitable  for  interchanging  documents  in  formatted  form,  processable 
form  or  formatted  processeible  form  and  has  been  defined  in  accordance  with  [ISO 
8613-1 jcciTT  Recommendation  T.411].    The  format  of  this  profile  is  in  accordance 
with  the  standardized  proforma  and  notation  defined  in  Addendum  1-Annex  F  of 
[ISO  86 13-1 1 CCITT  Recommendation  T.411]. 
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International  Standardized  Profile  (ISP) 
FOD26: 

Information  technology  - 

International  standardized  Profile  FOD26  - 
Office  Document  Foinnat:  Enhanced  Document  Structure  - 
Cheuracter,  Raster  Graphics  and  Geometric  Graphics 
content  architectures 


Part  1: 

Document  implication  Profile 
1  Scope 

This  profile  specifies  interchange  formats  for  the  transfer  of  structured 
documents  between  equipment  designed  for  word  or  document  processing.  Such 
documents  may  contain  character,  raster  graphics  and  geometric  graphics  content. 

The  documents  that  can  be  interchanged  using  this  profile  range  from  simple 
documents  to  highly  structured  technical  reports,  articles  and  typeset  documents 
such  as  brochures.    This  profile  provides  a  comprehensive  level  of  features  for 
the  transfer  of  documents  between  these  systems. 

This  profile  allows  documents  to  be  interchanged  in  the  following  forms: 

a)  formatted  form; 

b)  processable  form; 

c)  formatted  processeible  form. 

The  architecture  levels  defined  for  these  three  forms  have  matching 
functionalities  so  that  the  interchange  formats  of  a  document  are  convertible 
from  a  processeJsle  form  to  any  other  form. 

This  profile  is  independent  of  the  processes  ceurried  out  in  an  end  system  to 
J    create,  edit  or  reproduce  dociiments.    It  is  also  independent  of  the  means  to 
'I    transfer  documents  which,  for  example,  may  be  by  me2ms  of  communication  links  or 
storage  media. 

A  document  structured  in  accordance  with  this  Isp  is  represented  for  interchange 
by  one  of  two  DAPs.    One  DAP  uses  the  Office  Document  Interchange  Format  (ODIF), 
the  other  DAP  uses  the  Office  Document  Language  (ODL),  both  as  defined  in  ISO 
8613-5. 

When  this  document  refers  to  this  profile,  it  is  referring  to  either  of  the 
document  application  profiles  defined  by  .this  specification. 
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2       normative  Bsferoaces 

The  following  documents  contain  provisions  which,  through  reference  in  this  text 
constitute  provisions  of  this  specification.    At  the  time  of  publication  the 
editions  indicated  were  valid.    All  documents  are  subject  to  revision  and 
peurties  to  agreements  based  on  this  specification  are  warned  against 
automatically  applying  any  more  recent  editions  of  the  documents  listed  below, 
since  the  nature  of  references  made  by  profiles  to  such  documents  is  that  they 
may  be  specific  to  a  particular  edition.    Members  of  lEC  and  ISO  maintain 
registers  of  currently  valid  International  Standards  and  ISPs.    The  CCITT 
secretariat  maintains  a  list  of  currently  valid  CCITT  recommendations. 

ISO  8613-1  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  tart  1:  Introduction  and 
general  principles; 

ISO  8613-2  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  2:  Document 
structures; 

ISO  8613-4  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  4:  Document  profile; 

ISO  8613-5  :  1989,  Infoxmation  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  5:  Office  document 
interchange  format; 

ISO  8613-6  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  6:  Character  content 
architectures ; 

ISO  8613-7  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  7:  Raster  graphics 
content  architectures; 

ISO  8613-8  :  1989,  Information  processing  -  Text  and  office  systems;  Office 
Document  Architecture  (ODA)  and  interchange  format  -  Part  8:  Geometric  graphics 
content  architectures; 

ISO  8613-1  :  Addendum  1:    Information  processing  -  Text  and  office  systems; 
office  Document  Architecture  (ODA)  and  interchange  format  Part  1:  Introduction 
and  general  principles.  Addendum  1  -  Annex  F:  A  Document  Application  Profile 
proforma  and  notation; 

CCITT  Recommendation  T.4  -  standardization  of  group  3  facsimile  apparatus  for 
document  transmission  (1988); 

CCITT  Recommendation  T.6  -  Facsimile  coding  schemes  and  coding  control  functions 
for  group  4  facsimile  apparatus  (1988); 

ISO/IEC  646  :  1991,  Information  technology  -  ISO  7-bit  coded  character  set  for 

information  interchange; 
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ISO  8859-1  :  1987,  Information  processing  -  8-bit  Single-byte  coded  graphic 
character  sets  -  Part  1j  Latin  alphabet  No,  1; 

ISO  6937-2  :  1983,  Information  processing  -  Coded  character  sets  for  text 
communication  -  Part  2 :  Latin  alphabetic  and  non-alph2ibetic  graphic  characters ; 

ISO  6937-2  Addendum  1  :  1989,  Information  processing  -  Coded  character  sets  for 
text  communication  -  Part  2:  Latin  alphabetic  and  non-alphabetic  graphic 
characters.  Addendum  1; 

ISO  2022  :  1986,  Information  processing  -  ISO  7-bit  and  8-bit  coded  character 
sets  -  Code  extension  techniques; 

ISO  2375  :  1985,  Data  processing  -  Procedure  for  registration  of  escape 
sequences ; 

ISO  7350  :  1984,  Text  communication  -  Registration  of  graphic  character 
subrepertoires ; 

ISO  8824  :  1987,  Information  processing  systems  -  Open  Systems  Interconnection  - 
As  tract  Syntax  Notation  One  (ASN.l); 

ISO  8825  :  1987,  Information  processing  systems  -  Open  Systems  Interconnection  - 
Basic  encoding  rules  for  abstract  syntax  notation  one  (ASN.l); 

ISO  8879  I  1986,  Information  processing  -  Text  and  office  systems  -  standard 
Generalized  Markup  Language  ( SGML ) ; 

ISO  9069  :  1988,  Information  processing  -  SGJCL  support  facilities  -  SGML 
Document  Interchange  Format  ( SDIF ) ; 

ISP  10610-1  !  1992,  Information  technology  -  International  standardized  Profile 
FODll  -  office  Document  Format:  Simple  document  structure  -  Character  content 
architecture  only  -  Peurt  1:  Document  Application  Profile. 

ISP  11182-1  :  1992,  Information  technology  -  International  Standardized  Profile 
FOD36  -  Office  Docvunent  Formats  Extended  document  structure  -  Chsuracter,  Raster 
Graphics  and  Geometric  Graphics  content  architectures  =■  Part  1:  Document 
Application  Profile. 

ISO/IEC  TR  10000-1 s  1990,  Information  Technology  -  Framework  and  taxonomy  of 
International  standardized  Profiles  -  Part  1:  Framework 

ISO/IEC  TR  10000-2 J  1990,  Information  Technology  -  Framework  and  taxonomy  of 
International  Standardized  Profiles  -  Part  2  Taxonomy  of  Profiles 
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3  Definitions 


For  the  pxirposes  of  this  specification,  the  following  definitions  apply. 

The  definitions  given  in  [ISO  8613-1 |cciTT  Recommendation  T.411]  are  applicable  i 
to  this  profile.  i 


Constituent  names 

Each  constituent  that  may  be  included  in  a  document  that  conforms  to  this 
profile  has  been  given  a  unique  name  which  serves  to  identify  that  constituent 
throughout  this  profile. 

The  convention  is  that  full  names  are  used  (i.e.,  no  abbreviations  are  used), 
two  or  more  words  in  a  name  are  concatenated  and  each  word  begins  with  a 
capital.  Examples  of  constituent  names  used  in  this  profile  are  BodyText, 
Footnote,  RectoPage  and  ColumnFixed. 

In  clause  6  each  constituent  provided  by  this  profile  is  underlined  once  at  the 
point  in  the  text  at  which  the  purpose  of  that  constituent  is  defined.  This 
also  serves  to  identify  all  the  constituents  provided  by  this  profile. 

The  same  constituent  names  are  also  used  in  the  technical  specification  in 
clause  7  so  that  there  is  a  one-to-one  correspondence  between  the  use  of  these 
names  in  clause  6  and  7. 

Although  the  constituent  names  relate  to  the  purpose  of  the  constituents,  the 
semantics  of  constituents  shall  not  be  implied  from  the  actual  names  that  are 
used.  Also,  these  names  do  not  appear  in  an  interchanged  document  but  a 
mechanism  for  identifying  constituents  in  an  interchange  docviment  is  provided 
(see  6.6.4).    Thus  in  an  application  using  this  profile,  the  constituents  may  be 
known  to  the  user  by  different  names. 

4       Relationship  with  other  profiles 

This  profile  belongs  to  a  series  of  hiersurchically  related  profiles  which 
include  FODll  and  FOD36. 

The  features  supported  by  this  profile  are  a  superset  of  the  features  supported 
by  the  profile  FODll  and  thus  all  data  streams  that  are  conformant  to  FODll  are 
also  conformant  to  this  profile,  apart  from  the  DAP  identifier. 

Also  the  features  supported  by  this  profile  are  a  subset  of  the  features 
supported  by  the  profile  FOD36  and  thus  all  data  streams  conformant  to  this 
profile  are  also  conformant  to  FOD36,  apart  from  the  DAP  identifier. 

The  specification  of  the  DAPs  in  this  isP  is  identifical  to  the  specification 
defined  in  the  CCITT  Recommendation  T.505  (PM-26),  except  that  PM-26  only 
defines  the  use  of  the  ODIF  interchange  format. 
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5  Confozmance 

In  order  to  conform  to  this  profile,  a  data  etream  representing  a  docunent  shall 
neet  the  requirements  specified  in  5.1. 

This  part  of  the  ZSP  does  not  define  Implementation  support  requirements.  These 
requirements  are  defined  in  other  parts  that  make  use  of  this  ISP. 


5.1     Data  stream  conformance 

The  following  requirements  apply  to  the  encoding  of  data  streams  which  conform 
to  this  profile: 

a)  The  data  stream  shall  be  encoded  either  in  accordance  with  the  ASM.l 
encoding  rules  defined  in  ISO  8825  or  the  SGML  encoding  rules  defined 
in  ISO  8879; 

b)  The  data  stream  shall  be  structured  in  accor,dance  with  the 
interchange  formats  defined  in  clause  8; 

c)  The  document,  as  represented  by  the  data  stream  after  resolution  of 
any  external  references,  shall  be  structured  in  accordemce  with  one 
of  the  documents  architecture  classes  as  defined  in  6.1  and  shall 
contain  all  mandatory  constituents  specified  for  that  class;  other 
constituents  may  be  included,  provided  that  they  are  permitted  for 
that  class,  as  specified  in  clause  7; 

d)  Each  constituent  shall  contain  all  those  attributes  specified  as 
required  for  that  constituent  in  this  profile;  other  attributes  may 
be  specified  provided  that  they  are  permitted  for  that  constituent; 

e)  The  attribute  values  specified  shall  be  within  the  range  of 
permissible  values  specified  in  this  profile; 

f )  The  encoded  document  shall  be  constructed  in  accordance  with  the 
abstract  document  architecture  defined  in  [ISO  8613-2 jcciTT 
Recomnendation  T.412]; 

g)  The  document  shall  be  structxired  in  accordance  with  the 
chsuracteristics  and  constraints  specified  in  clause  6. 
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5.2      Zaplenentation  confornance 

i 

This  Bvibclause  states  the  requirements  for  implementations  claiming  conformance  ' 
to  this  profile.  ! 

A  conforming  receiving  implementation  shall  be  capable  of  receiving  either  any 
data  streams  conforming  to  this  profile  structured  in  accordance  with  ODIF  or 
any  data  streams  conforming  to  this  profile  structured  in  accordance  with  OOL  or  ( 
both  of  these.    Receiving  usually,  but  not  always,  involves  recognizing  and  ' 
further  processing  the  data  stream  elements.    The  explicit  meaning  of  I 
"receiving"  is  determined  by  another  part  of  this  ISP. 

A  receiving  system  which  claims  conformance  to  this  DAP  shall  be  capable  of  | 
handling  data  streams  which  are  conformant  to  DAPs  that  are  subordinate  to  this  1^ 
DAP  within  the  taxonomy  described  in  clause  4,  (ie.  FODll). 


6       Characteristics  supported  by  this  document  application  profile 

This  clause  describes  the  characteristics  of  documents  which  may  be  represented 
by  data  streams  conforming  to  this  profile.  This  clause  also  describes  how  these 
characteristics  are  represented  in  terms  of  constituent  constraints. 


6.1    Overview  \ 

6.1.1  General 

This  profile  supports  the  interchange  of  documents  in  the  following  forms: 

proces sable  form,  which  facilitates  the  revision  of  a  document  by  a 
recipient; 

formatted  foinn,  which  facilitates  the  reproduction  of  a  document  as 
intended  by  the  originator;  ' 

formatted  processable  form,  which  facilitates  the  reproduction  of  a 
docvunent  as  intended  by  the  originator  or  facilitates  the  revision  of 
a  document  by  a  recipient. 

In  addition  this  profile  supports  the  interchange  of: 

-  generic-dociiments; 

1 
I 

document  profile. 

The  constituents  that  make  up  these  five  classes  of  data  stream  are  defined  in  ' 

6.1.2  to  6.1.6.  Constituents  defined  as  'required'  shall  occur  in  any  data  ! 
stream  that  conforms  to  this  profile.  Constituents  listed  as  'optional'  may  or 
M*y  not  be  present  in  the  data  stream  depending  on  the  requirements  of  the 
particular  data  stream. 
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f 

Note  that  the  constituents  that  make  up  a  complete  document  that  is  conformant 
to  this  profile  include  all  those  referenced  and  contained  in,  if  any,  resource 
and  external  documents  ( see  6.6.1  and  6.6.2). 

6.1.2  Formatted  form  documents 
Required  constituents: 

a  document  profile; 

layout  object  descriptions  representing  a  specific  layout  structure. 
Optional  constituents: 

-  layout  object  class  descriptions  representing  a  'factor'  generic 
layout  structure; 

presentation  styles; 

-  content  portion  descriptions. 

6.1.3  Procesaable  form  documents 
Required  constituents: 

-  a  document  profile; 

logical  object  class  descriptions  representing  a  'complete'  or 
'partial'  generic  logical  structure; 

logical  object  descriptions  representing  a  specific  logical 
structure . 

Optional  constituents: 

layout  object  class  descriptions  representing  a  'complete'  generic 
layout  structure; 

layout  styles; 

presentation  styles; 

content  portion  descriptions. 

In  the  case  of  processable  form  documents,  when  the  generic  layout  structure  is 
not  present,  additional  restrictions  are  placed  on  the  layout  directives  that 
nay  be  included  in  layout  styles.  These  restrictions  are  defined  in  6.4.3. 
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6.1.4  Formatted  processable  form  dociments 
Required  constituents s  . 

-  a  document  profile; 

logical  object  class  descriptions  representing  a  'conqplete'  or 
/partial'  generic  logical  structure; 

-  logical  object  descriptions  representing  a  specific  logical 
structure; 

-  layout  object  class  descriptions  representing  a  'complete'  generic 
layout  structure; 

layout  object  descriptions  representing  a  specific  layout  structure. 
Optional  constituents: 

-  layout  styles; 

-  presentation  styles; 

•         content  portion  descriptions. 

6.1.5  Generic -documents 

A  generic -doc vunent  consists  of  one  of  the  following  sets  of  constituents: 
a) 

-  a  document  profile; 

logical  object  class  descriptions  which  represent  a  'complete' 
or  'partial'  generic  logical  structure; 

layout  styles  whose  presence  is  optional; 

presentation  styles  whose  presence  is  optional; 

-  generic  content  portions  whose  presence  is  optional. 


b) 


a  document  profile; 

layout  object  class  descriptions  which  represent  a  'complete' 
generic  layout  structure  or  'factor'  set; 

presentation  styles  whose  presence  is  optional; 

generic  content  portions  whose  presence  is  optional. 
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-  a  document  profile; 

'  -        logical  object  class  descriptions  which  represent  a  'complete' 

or  'partial'  generic  logical  structure; 

-  layout  object  class  descriptions  which  represent  a  'complete' 
generic  layout  structure; 

-  layout  styles  whose  presence  is  optional; 
presentation  styles  whose  presence  is  optional; 

-  generic  content  portions  whose  presence  is  optional. 

6.1.6    Docuaent  profile 

? 

This  form  of  document  contains  a  document  profile  only., 

>  6.2    Logical  characteristics 
'  6.2.1  Introduction 

'  This  subclause  defines  the  logical  constituent  constraints  provided  by  this 

profile  to  represent  the  characteristics  of  documents  containing  logical 
j  component  descriptions. 

j  Different  constituent  constraints  may  be  used  to  represent  emd  distinguish  parts 
I'  of  a  document  that  have  different  logical  characteristics.    This  subclause 
{:  describes  the  general  characteristics  and  typical  uses  of  the  constituent 
constraints  that  aze  provided. 

i 

I  The  descriptions  of  the  logical  characteristics  represented  by  each  of  the 

I  constituent  constraints  is  provided  for  guidance  only.  It  is  the  responsibility 

of  the  user  to  determine  how  a  document  is  to  be  represented  using  the 
j  constituents  provided.  Adherence  to  these  guidelines  can  enhance  the  mutual 
j  understanding  of  a  document  by  an  originator  and  a  recipient. 

I  6.2.2    Overview  of  the  logical  structure 

f 

j;  Prom  the  logical  point  of  view,  the  document  consists  of  two  paurts,  namely  a 

I  'body  part  and  a  'common'  part. 

The  'body  part  represents  the  main  content  of  a  document  and  is  intended  to  be 
I  reproduced  in  the  body  area  of  the  pages  that  make  up  the  document. 

I   The  'common'  part  represents  common  content  that  is  to  be  placed  in  reserved 
J    header  and  footer  areas  on  each  page  of  a  document.  Header  and  footer  content 

are  independently  optional  and  so  may  be  included  in  an  interchanged  document 

only  if  required. 
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6.2.3    Body  part  of  the  logical  structure 

6.2.3.1  DocuisentlxsgicalRoot 

DocumentLogicalRoot  is  a  constituent  constraint  representing  the  top  level  in 
the  document  logical  structure.  Its  iamaediate  subordinates  consist  of  a  sequence 
of  one  or  more  constituent  constraints  of  the  type  Passage. 

The  automatic  numbering  schemes  that  apply  to  constituent  constraints  of  the 
types  MumberedSegment  and  Footnote  may  be  initialised  on  the 
DocumentLogicalRoot . 

6.2.3.2  Passage 

Passage  is  a  constituent  constraint  that  represents  the  first  level  of  logical 
subdivision  of  a  document.  It  may  be  used  to  indicate  a  logical  grouping  of 
subordinate  parts  of  a  document  that  are  to  be  regarded  as  an  entity  for  reading 
or  that  have  common  layout  and  presentation  characteristics.  For  example: 

Passages  are  typically  used  to  represent: 

-  the  contents  to  be  placed  on  the  title  page  of  a  report; 

-  the  front  matter  in  the  table  of  contents  or  foreword; 

-  the  main  matter  of  the  document; 

the  back  matter,  consisting  of  appendices,  glossary  or  index. 

The  automatic  numbering  schemes  that  apply  to  subordinate  constituent 
constraints  of  the  types  Numberedsegment  and  Footnote  may  be  initialised  on  a 
Passage. 

The  immediate  subordinates  of  a  Passage  consist  of  an  optional  arbitrary  ordered 
sequence  of  one  or  more  of  the  following  constituent  constraint  types: 

-  Paragraph; 
BodyGeometric ; 

-  BodyRaster; 
BodyText. 

These  may  be  optionally  followed  by  one  or  more  constituent  constraints  of  the 
type  Numberedsegment. 

A  Passage  shall  have  at  least  one  of  the  above  constituent  constraint  types  as  a 
subordinate . 

A  document  may  contain  several  different  class  definitions  of  the  type  Passage, 
each  of  which  defines  the  common  characteristics  of  sets  of  Passages  within  the 
document  such  as  their  allowed  subordinates  or  layout  properties.  For  example,  a 
class  of  Passages  may  be  defined  which  always  begin  on  a  new  page  set. 
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I  6.2.3.3  NunberedSegment 

NumberedSegment  is  a  constituent  constraint  that  represents  a  logical 
I  subdivision  within  a  document  that  is  distinguished  by  an  identifier.  The 
logical  subdivision  may  be  a  subdivision  of  a  Passage  or  another  higher  level 
NumberedSegment.    The  logical  subdivision  may  also  have  some  common  layout 
(|  characteristics. 

I  The  automatic  n\imbering  schemes  that  apply  to  subordinate  constituent 
constraints  of  the  types  NumberedSegment  and  Footnote  may  be  initialised  on  a 
Passage. 

I  The  immediate  subordinates  of  a  NumberedSegment  consist  of  the  constituent 
I  constraint  Number,  whose  presence  is  mandatory  and  serves  to  carry  the 
identifier  of  the  NumberedSegment.  This  is  followed  by  an  optional  arbitreuzy 
ordered  sequence  of  one  or  more  of  the  following  constituent  constraints: 

Paragraph; 

-  BodyGeometr ic ; 
BodyRaster; 
BodyText . 

These  are  optionally  followed  by  a  sequence  of  one  or  more  constituent 
constraints  of  the  type  NumberedSegment.  Hence  a  document  may  contain  any  number 
of  nested  levels  of  the  constituent  NumberedSegment. 

A  NumberedSegment  is  typically  used  to  represent  entities  such  as  chapters, 
sections,  nested  sub-sections  and  appendices  which  contain  an  identifier  that 
serves  to  distinguish  that  entity  for  human  comprehension. 

A  document  may  contain  any  number  of  different  class  definitions  of 
NumberedSegment  which  define  the  common  characteristics  of  sets  of 
NumberedSegments ,  such  as  their  allowed  subordinates  and  layout  properties. 

Class  definitions  of  NumberedSegments  may  be  recursively  defined.     In  this  case 
only  one  call  of  NumberedSegment  may  be  specified,  and  the  <simple-expr> 
construction  in  the  macro  USENUMBERSTRINGS  in  the  bindings  attribute  of  this 
class  shall  use  the  optional  ORD  construction  only.     If  the  recursive  class 
definitions  are  used  for  NumberedSegment,  the  following  constraints  will  also 
apply.    For  all  levels  which  reference  recursively  defined  classes: 

-  numbering  format  will  be  the  same; 

-  no  initial  value  other  than  1  or  re-initialisation  of  the  numbering  is 
possible; 

-  it  is  not  possible  to  continue  the  numbering  across  Passages. 

If  class  definitions  are  not  recursive  in  this  way,  there  shall  be  one  and  only 
one  class  definition  for  NumberedSegements  corresponding  to  each  level  of 
numbering  within  each  Passage.     Class  definitions  may  be  shared  between 
NumberedSegments  belonging  to  different  Passages  but  they  shall  then  be  used  at 
the  same  level. 
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6.2.3.4  Mumbsr 

Nunber  is  a  constituent  constraint  that  represents  the  identifier  of  a 
NunberedSegment  to  which  it  is  subordinate.  This  identifier  allows  the 
Numberedsegment  to  be  distinguished  within  the  document  for  machine  processing 
or  human  comprehension. 

A  Number  is  a  basic  logical  constituent  which  contains  a  content  generator 
which,  when  evaluated,  produces  the  identifier  referred  to  above.  This 
evaluation  takes  place  during  the  layout  process. 

The  identifiers  are  structured  and  consist  of  a  sequence  of  one  or  more  numerals 
that  allow  NumberedSegments  at  the  same  or  different  levels  in  a  document 
structure  to  be  uniquely  distinguished.  The  ntimerals  nay  be  represented  by 
Arabic  or  Roman  numerals  or  by  their  alphabetic  equivalent  in  lower  or  upper 
case  characters  (the  number  1  is  represented  by  'A'  etc.).  Each  numeral  in  an 
identifier  is  distinguished  by  means  of  'separator'  characters  such  as  spaces 
and  full  stops  (the  character  "period");  a  typical  example  is  '6.2.3.4'. 

« 

MOTE:  The  separator  may  if  required  be  an  empty  string. 

Further  details  of  the  structure  and  generation  of  the  identifiers  are  given  in 
6.6.7. 

6.2.3.5  Paragraph 

Paragraph  is  a  constituent  constraint  that  is  a  subdivision  of  a  Passage  or 
NiimberedSegment .  It  is  typically  used  to  represent  the  grouping  of  psirts  of  a 
document  that  deals  with  a  single  theme  or  topic.  These  parts  may  consist  of 
character,  raster  graphics  and  geometric  graphics  content. 

The  immediate  subordinates  of  a  Paragraph  consist  of  an  eurbitrstry  ordered 
sequence  of  one  or  more  of  the  following  constituent  constraints: 

BodyText; 

BodyRaster; 

BodyGeometric ; 

Footnote . 

Content  from  any  subordinate  basic  text  objects  within  a  paragraph  may  be  run  on 
one  from  another  (that  is,  to  continue  on  the  same  line)  by  use  of  the 
Concatenation  featvire  (see  6.4.2.5).    Alternatively,  content  from  sxibordinates 
of  a  paragraph  nay  be  separated  one  from  another  to  give  white  space  between 
them,  using  Separation  (see  6.4.2.2).    This         be  used  to  give  an  effect 
similar  to  that  achieved  with  empty  lines  of  text.    Use  of  empty  text  lines  to 
achieve  white  space  between  areas  of  text  or  other  content  may  lead  to 
unintended  blank  areas  adjacent  to  the  leading  edge  of  layout  objects  (eg  at 
page  breaks)  whereas  the  use  of  Sepeiration  avoids  this. 
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i  constituents  of  the  type  BodyText  may  be  'concatenated'  to  form  a  continuous 
stream  of  character  content  which  is  laid  out  as  a  single  unit,  sequences  of 

!  constituents  of  the  types  BodyText  and  Footnote  may  be  concatenated  to  represent 
a  stream  of  character  content  with  embedded  footnotes.  Multiple  embedded 
footnotes,  which  may  be  consecutive  without  intervening  text,  may  be  included  in 
the  content. 

Another  typical  use  of  a  Paragraph  is  to  represent  a  group  of  document  parts 
I  that  have  common  layout  chauracteristics^.  An  example  is  a  graphical  illustration 
with  associated  text  which  is  to  be  laid  out  in  a  particular  frame. 

I  6.2.3.6    BodyText,  BodyRaster  and  BodyGeometric 

BodyText,  BodyRaster  and  BodyGeometric  are  constituent  constraints  which 
represent  the  lowest  level  of  logical  subdivision  of  a  document.  These 
constituent  constraints  are  subdivisions  of  Passages,  NumberedSegments  and 
j  Paragraphs.  They  allow  the  layout  and  presentation  requirements  of  different 
parts  of  a  docvunent  to  be  specified. 

These  are  basic  logical  constituents  that  directly  refer  to  content  portions 
that  contain  character,  raster  graphics  and  geometric  graphics  content 
respectively.  BodyText  shall  refer  to  one  or  more  content  portions  each 
containing  processable,  formatted  or  formatted  processaJale  character  content. 
BodyRaster  and  BodyGeometric  shall  only  refer  to  a  single  content  portion 
containing  formatted  processable  raster  graphics  content  or  formatted 
processable  geometric  graphics  content  respectively. 

constituents  of  these  types  in  the  generic  logical  structure  may  refer  to 
j  generic  content.  This  provides  the  means  of  defining  common  content  within  the 
body  part  of  a  document. 

6.2.3.7  Footnote 

Footnote  is  a  constituent  constraint  that  is  a  subdivision  of  a  Paragraph  and  is 
used  to  represent  footnotes  within  a  document. 

A  footnote  is  an  amount  of  content  that  is  logically  associated  with  a 
particular  part  of  the  document  body  but  which  is  intended  to  be  read  and  laid 
out  separately  from  its  associated  part  of  the  document.  Typically,  a  footnote 
consists  of  a  footnote  identifier,  which  is  embedded  within  the  document  body, 
!  and  the  footnote  itself,  which  is  laid  out  elsewhere. 

A  Footnote  is  a  composite  logical  constituent  whose  immediate  subordinates 
consist  of  the  constituent  constraint  FootnoteRef erence,  which  represents  the 
footnote  identifier,  followed  by  the  constituent  constraint  FootnoteBody,  which 
!  represents  the  footnote  itself.  Both  of  these  subordinates  are  mandatory. 
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€.2.3.8  FootnoteReferenee 

FootnoteReference  is  a-  constituent:  constraint  that  is  used  to  represent  a 
footnote  reference  within  the  body  of  a  document. 

FootnoteReference  is  a  basic  logical  constituent  that  contains  a  content 
generator  which  when  evaluated  produces  a  character  string  which  constitutes  the 
footnote  reference  referred  to  above. 

The  generated  character  string  consists  of  a  label  with  optional  prefix  and 
suffix  character  strings.  The  label  is  used  to  uniquely  identify  a  particular: 
footnote  and  may  consist  of  a  number  which  is  represented  in  the  form  of  Arabic 
or  Roman  numerals  or  by  an  alphabetic  equivalent.  The  number  may  be 
automatically  generated  so  that  its  value  is  incremented  for  each  successive 
footnote.  Alternatively,  the  label  may  consist  of  a  user  defined  cheuracter 
string . 

In  a  sequence  of  footnotes,  automatic  and  user  defined  labels  may  be  freely 
mixed  (giving  for  example  the  sequence  1,2*, 3, 4).     If  the  label  consists  of  a 

Qser-defined  character  string,  the  automatically  generated  number  sequence  is 
not  incremented. 

An  example  of  a  footnote  reference  is  '{2)'  where         and         are  user  defined 
prefix  and  suffix  strings  respectively  and  '2'  is  the  automatically  generated 
label.  Another  example  is  'note^'  where  '5'  is  the  label  and  'note'  is  a  prefix 
string  which  also  contains  the  control  function  PLU  to  enable  the  label  to  be 
represented  in  the  form  of  a  superscript.     In  this  case,  a  suffix  string 
containing  the  control  function  PLD  would  be  required  to  cause  the 
superscripting  to  be  cancelled  before  the  following  text. 

The  format  of  th©  content  generator  referred  to  above  is  described  in  6.6.8. 

S .  2 . 3 . 9  FootnoteBody 

FootnoteBody  is  a  constituent  constraint  which  represents  the  content  of  a 
footnote . 

FootnoteBody  is  a  composite  logical  constituent  whose  subordinates  consist  of 
the  constituent  constraint  FootnoteNumber ,  which  is  mandatory  and  represents  the 
footnote  identifier,  followed  by  a  sequence  of  one  or  more  constituent 
constraints  of  the  type  FootnoteText  which  represents  the  footnote  content.  The 
identifier  referred  to  above  is  identical  to  the  corresponding  footnote 
identifier  which  is  embedded  in  the  content  of  the  document  body  and  represented 
by  the  constituent  constraint  FootnoteReference. 

The  constituents  subordinate  to  FootnoteBody  are  intended  to  be  laid  out 
separately  from  the  other  parts  of  the  document  content.  When  a  generic  layout 
structure  is  specified  for  the  dociment,  these  constituents  are  constrained  to 
be  laid  out  in  a  FootnoteArea  frame  ( see  6.3.5.9). 
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6.2.3.10  FootnoteNumber 

i  I  FootnoteNumber  is  a  constituent  constraint  that  represents  the  footnote 
I  identifier  within  the  footnote  body . 

This  identifier  is  identical  to  the  content  associated  with  the  constituent 
1 1  constraint  FootnoteReference  but  is  intended  to  be  laid  out  so  that  it 
l^j  immediately  precedes  the  content  of  the  footnote  body. 

I  FootnoteNumber  is  a  basic  logical  constituent  that  contains  a  content  generator 
I  which  when  evaluated  produces  the  identifier  referenced  above.  The  foruat  of 

this  content  generator  is  the  same  as  the  content  generator  that  may  be 

specified  for  the  constituent  constraint  FootnoteReference. 

It  is  required  to  specify  the  layout  category  name  'Footnote'  for  this 
j  constituent.    This  along  with  a  permitted  categories  attribute  of  'Footnote'  on 
y  the  footnote  frame  will  ensure  that  this  constituent  is  laid  out  in  a 

FootnoteArea  frame  when  generic  layout  structure  is  specified  within  the 

document . 

6.2.3.11  FootnoteText 

FootnoteText  is  a  constituent  constraint  that  is  used  to  represent  the  footnote 
content.  It  is  the  lowest  logical  subdivision  of  a  FootnoteBody . 

FootnoteText  is  a  basic  logical  constituent  that  references  one  or  more  content 
portions  each  containing  processable,  formatted  or  formatted  processable 
character  content. 

It  is  required  to  specify  the  layout  category  name  'Footnote'  for  this 
constituent.    This  along  with  a  permitted  categories  attribute  of  'Footnote'  on 
the  footnote  frame  will  ensure  that  this  constituent  is  laid  out  in  a 
FootnoteArea  frame  when  generic  layout  structure  is  specified  within  the 
dociiment . 

6.2.4    Common  content  part  of  the  logical  structure 

6.2.4.1  CoimnonContent 

j  Commoncontent  is  a  constituent  constraint  that  represents  common  content  that  is 
'l  to  be  laid  out  in  the  header  and  footer  areas  of  the  pages  of  a  document.  Common 

content  consists  of  any  combination  of  character,  raster  graphics  and  geometric 
:  graphics  content. 
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Any  number  of  constituent  constraints  of  the  type  commonContent  may  be  containec 
in  a  document.  CommonContent  is  a  composite  logical  object  class  whose  immediat 
subordinates  consist  of  an  arbitreucy  ordered  sequence  of  one  or  more  of  the 
following  constituent  constraints: 

-  CommonText; 
PageNumber; 

-  CommonRaster; 

-  CommonGeometric . 

When  the  generic  layout  stiructure  is  present,  constituents  of  the  type 
CommonContent  and  their  associated  subordinate  constituents  are  constrained  to 
be  laid  out  in  frames  representing  header  or  footer  areas  using  the  'logical 
source'  mechanism  (see  6.3.€). 

S.2.4.2  CommonTezt 

CommonText  is  a  constituent  constraint  that  represents  the  common  character 
content  that  is  to  be  laid  out  in  the  header  or  footer  area  of  a  document.  For 
example,  header  or  footer  content  that  appears  on  each  page  in  a  sequence  of 
pages  may  be  represented  by  this  constituent. 

CommonText  is  a  basic  logical  object  class  that  references  one  or  more  content 
portions  each  containing    processable,  formatted  and  formatted  processable 
character  content. 


6.2.4.3  PageNumber 

PageNumber  is  a  constituent  constraint  that  represents  the  common  character 
content  that  is  to  be  laid  out  in  the  header  or  footer  area  of  a  document.  This 
constituent  is  specifically  used  when  it  is  required  to  present  a  header  or 
footer  content  which  contains  an  automatically  generated  page  number. 

PageNumber  is  a  basic  logical  object  class  that  contains  a  content  generator. 
This  content  generator  contains  a  reference  to  a  page  number  which  is 
automatically  evaluated  when  the  docximent  is  laid  out.  This  provides  the  means 
of  representing  the  page  numbers  that  are  displayed  on  the  consecutive  pages  of 
a  document. 

Each  page  number  consists  of  a  single  number  which  may  be  represented  in  the 
form  of  ATedsic  or  Roman  numerals  or  in  its  alphabetic  equivalent.  Page  numbering 
schemes  may  start  at  0  or  any  value  greater  than  0. 

The  format  of  the  content  generators  is  defined  in  6.6.6. 
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6.2.4.4  ConmonRaster 

I 

j  commonRaater  is  a  constituent  constraint  that  represents  the  common  raster 
i  graphics  content  that  is  to  be  laid  out  in  the  header  or  footer  airea  of  a 
I  document.  For  ex2unple,  this  constraint  may  be  used  to  represent  a  logo  which  ia 
to  be  laid  out  on  each  page  of  a  document. 

Common  raster  is  a  basic  logical  object  class  which  references  a  single  content 
portion  containing  formatted  processable  raster  graphics  content. 

6.2.4.5  CcmmonGeometric 

CommonGeometric  is  a  constituent  constraint  that  represents  the  common  geometric 
graphics  content  that  is  to  be  laid  out  in  the  header  or  footer  area  of  a 
document.  For  example,  this  constraint  may  be  used  to  represent  a  graphical  icon 
which  is  to  be  laid  out  on  each  page  of  a  document. 

Commongeometric  is  a  basic  logical  object  class  which  references  a  single 
content  portion  containing  formatted  processedsle  geometric  graphics  content. 

6.3    Layout  characteristics 

This  subclause  defines  the  layout  constituent  constraints  provided  by  this 
profile  to  represent  the  characteristics  of  documents. 

Different  constituent  constraints  may  be  used  to  represent  and  distinguish  parts 
of  a  document  that  have  different  layout  characteristics.  This  subclause 
describes  the  general  characteristics  and  typical  uses  of  the  constituent 
constraints  that  are  provided. 

The  descriptions  of  the  layout  chaoracteristics  represented  by  each  of  the 
constituent  constraints  is  provided  for  guidance  only.  It  is  the  responsibility 
of  the  user  to  determine  how  a  document  is  to  be  represented  using  the 
constituents  provided.  Adherence  to  these  guidelines  can  enhance  the  mutual 
understanding  of  a  document  by  an  originator  and  a  recipient. 

6.3.1    Overview  of  the  layout  characteristics 

The  document  structvire  allows  the  document  content  to  be  laid  out  and  presented 
in  one  or  more  page  sets.  Each  page  set  may  be  used  for  different  parts  of  the 
document,  for  example,  the  title  page,  foreword,  table  of  contents,  document 
body  emd  appendices. 

Each  page  set  consists  of  a  series  of  pages.  In  general,  each  page  may  be  sub- 
divided into  three  areas:  the  body  area.,  which  is  used  to  layout  the  document 
body;  and  the  header  and  footer  areas,  which  may  be  used  to  layout  the  common 
content . 
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Four  page  layout  types  are  supported  by  this  profile.  Each  page  layout  type 
specifies  how  the  body,  header  and  footer  areas  are  positioned  within  each  page 
and  how  the  content  nay  be  presented  within  each  of  those  areas.  These  four 
types  are  referred  to  as  page  layouts  A,  B,  C  and  D  and  are  illustrated  in 
figures  1,  2,  3  and  4  respectively. 

It  is  intended  that  all  applications  which  use  this  profile  ahall  support  page 
layout  A,  whereas  support  for  the  other  three  page  layouts  aay  be  specified  as 
optional . 

Page  layout  A  is  used  when  the  character  content  is  to  be  laid  out  horizontally 
(from  left  to  right  or  from  right  to  left)  and  from  top  to  bottom  within  the 
body  area.  This  layout  is  typically  used  for  documents  written  in  Latin  based, 
Hebrew  and  Arabic  languages. 

Page  layout  B  is  used  when  the  chairacter  content  is  to  be  laid  out  vertically 
(bottom  to  top  or  top  to  bottom)  and  from  left  to  right  within  the  body  area. 
This  layout  is  typically  used  for  documents  written  in  Latin  based,  Hebrew  and 
Arabic  languages  in  which  it  is  required  to  layout  the  content  in  landscape 
orientation  within  the  body  area  of  the  page. 

Page  layouts  C  and  D  are  used  when  the  cheoracter  content  is  to  be  laid  out 
vertically  and  from  right  to  left  within  the  body  area.  These  layouts  are 
typically  used  in  documents  written  in  languages  which  use  ideograms,  such  as 
Japanese  and  Chinese  cheuracters. 

The  body  area  may  be  further  sub-divided  into  areas  composed  of  single  and 
multiple  columns  and  an  area  may  be  reserved  for  footnotes.  In  addition,  the 
header  and  footer  areas  may  be  sub-divided  to  allow  the  representation  of 
different  content  types. 


6.3.2  DocumentXayoutRoot 

DocumentLayoutRoot  is  a  constituent  constraint  that  represents  the  top  level  in 
the  document  layout  structure.  Its  immediate  subordinates  consist  of  a  sequence 
of  one  or  more  constituents  of  the  type  PageSet.  The  numbering  schemes  for  pages 
may  be  initialised  on  this  constituent  constraint. 

6.3.3  PageSet 

Paqeset  is  a  constituent  constraint  that  represents  a  grouping  of  pages  within  a 
document.  A  PageSet  is  typically  used  to  represent  a  part  of  a  document  that  has 
different  layout  requirements  from  other  parts  of  a  document.  Also,  a  PageSet 
may  correspond  to  a  part  of  a  document  that  has  a  certain  logical  significance, 
for  example,  a  PageSet  might  represent  the  front  matter  in  a  document  or  an 
individual  chapter. 
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Only  one  level  of  PageSet  is  allowed  in  a  document.  However,  a  document  nay 
contain  any  number  of  class  definitions  of  the  type  PageSet  which  may  be  used, 
for  example,  to  provide  a  choice  of  alternative  layouts  for  different  peurts  of  a 
document  or  to  specify  the  exact  layout  requirements  for  each  successive  pjurt  of 
a  document. 

The  immediate  subordinates  of  a  PageSet  consist  of  a  combination  of  constituent 
constraints  of  the  types  Page,  RectoPage  and  VersoPage,  as  described  in  6.3.4.1. 

€.3.4    Page  characteristica 
6.3.4.1    Page  constituents 

Three  constituent  constraints  are  provided  to  represent  the  pages  within  a 
document,  namely  Page,  RectoPage  and  VersoPage . 

The  only  difference  in  the  characteristics  of  these  types  of  constituent 
constraints  concerns  the  values  that  may  be  specified  for  the  parameter  "side  of 
sheet*  in  the  attribute  "medium  type",  in  the  case  of  Page,  the  value  of  this 
parameter  may  be  specified  as  'recto',   'verso'  or  'unspecified'.  In  the  case  of 
RectoPage,  the  value  of  this  parameter  may  be  specified  as  'recto'  or 
'unspecified';  in  the  case  of  VersoPage,  the  value  of  this  parameter  may  be 
specified  as  'verso'  or  'unspecified'.    The  values  "recto"  and  "verso"  of  the 
"side  of  sheet"  parameter  of  the  "medium  type"  attribute  are  non-basic. 

The  pages  that  make  up  a  page  set  consist  of  an  optional  initial  page  which  is 
represented  by  the  constituent  constraint  Page  and  which  is  optionally  followed 
by  either: 

a)  A  sequence  of  pages  represented  by  the  constituent  constraint  Page. 
All  pages  in  this  sequence  shall  have  the  same  layout  characteristics 
(see  note)  but  these  characteristics  may  differ  from  those  of  the 
initial  page. 

b)  A  sequence  of  pages  which  are  intended  to  be  laid  out  alternatively 
on  the  'recto'  and  'verso'   (or  on  the  'verso'  and  'recto')  sides  of 
the  presentation  medium  and  are  represented  by  the  constituent 
constraints  RectoPage  and  VersoPage  respectively.  All  pages  in  this 
sequence  shall  have  the  same  layout  characteristics  (see  note)  but 
these  chetracteristics  may  differ  from  those  of  the  initial  page. 

Pages  having  the  same  layout  characteristics  are  pages  that  have  the  same  page 
layout  (see  6.3.4.5)  and  for  which  the  body  area,  header  area  (if  present)  and 
footer  area,  (if  present)  have  the  same  dimensions  and  positions  within  the  page 
(see  6.3.4.3).    Pages  having  the  same  layout  characteristics  do  not  necessarily 
have  the  Scune  position  on  the  presentation  medium  (see  6.3.4.4). 

A  page  set  shall  contain  at  least  one  page. 

An  initial  page  is  typically  used  at  the  beginning  of  a  document  or  of  a  section 
within  a  document.  It  may  be  used,  for  example,  for  a  title  page  whose  layout 
requirements  differ  from  the  following  pages. 
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The  following  restrictions  also  apply  to  the  pages  within  a  page  set: 


i) 


all  the  pages  shall  have  the  same  dimensions  and  orientation  (see 
6.3.4.2); 


ii)      all  pages  are  to  be  laid  out  on  the  same  size  of  presentation  aediusi 
( see  6.3.4.3). 


6.3.4.2    Page  dinansiona 

The  dimensions  of  the  pages  nay  be  specified  as  any  value  (in  BMUs)  that  is 
equivalent  to  or  less  than  ISO  A3  or  ANSI  B  paper  sizes  in  portrait  or  landscape 
orientation.  The  dimensions  nay  be  specified  in  portrait  or  landscape 
orientation.    Japanese  page  sizes  34  and  B5  are  also  supported  but  the 
dimensions  of  these  pages  lie  within  the  range  of  dimensions  given  above. 

Dimensions  equivalent  to  or  less  than  the  common  assure^d  reproduction  area  of  J 
ISO  A4  and  ANSI-A  in  portrait  or  landscape  orientation  are  basic  values.  Larger 

page  sizes  are  non-basic  and  their  use  shall  be  indicated  in  the  document  { 

profile .  I'l 


Any  default  page  dimensions  nay  be  specified  in  the  document  profile  subject  to  1 
the  maximum  dimensions  defined  above.  j 


NOTE  -  The  size  termed  "North  American  Letter  (NAL)"  in  ISO  8613  (e.g.  in  i 
ISO  8613-2,  clause  7)  is  in  this  specification  called  "ANSI  A"  in  order  to 
be  consistent  with  the  other  reference  to  ANSI  standard  paper  sizes. 


6.3.4.3    Nominal  page  sizes 

The  nominal  page  sizes  that  may  be  specified  are  listed  in  table  1.  These  nay  be 
specified  in  portrait  or  landscape  orientation.  All  values  of  nominal  page  size 
are  non-basic  and  hence  all  values  used  in  a  document  shall  be  indicated  in  the 
document  profile. 

Any  value  of  nominal  page  size  defined  in  tedale  1,  subject  to  the  restrictions 
specified  above,  nay  be  specified  as  the  default  value  in  the  document  profile. 

Table  1  also  includes  the  recommended  assured  reproduction  area  (ARA) . 
Information  loss  nay  occur  when  a  document  is  reproduced  if  the  dimensions  of 
constituent  constraints  of  the  type  page  exceed  the  ARA  for  the  specified 
nominal  page  size. 
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Page  type 

size  in  inches 
or  millimetres 

Size  in  BMUs 

ARA  in  BMUs 

ISO  AS 

148mm  x  210nm 

7 

OlS 

X 

9 

920 

not  defined 

ISO  A4 

210mm  X  297nm 

9 

920 

X 

14 

030 

9  240  X  13 

200 

ISO  A3 

297mm  x  420mm 

14 

030 

X 

19 

840 

13  200  X  18 

480 

ANSI  legal 

8. Sin.  X  14in. 

10 

200 

X 

16 

800 

9  240  X  15 

480 

ANSI  A 

8. Sin.  X  llin. 

10 

200 

X 

13 

200 

9  240  X  12 

400 

ANSI  B 

llin.    X  17in 

13 

200 

X 

20 

400 

12  744  X  19 

656 

Japan-legal 

2S7mm    x  364mm 

12 

141 

X 

17 

196 

11  200  X  15 

300 

Japan-letter 

182mm    x  2S7mm 

8 

598 

X 

12 

141 

7  600  X  10 

200 

6.3.4.4    Page  offset 

The  page  offset  is  the  distance  of  the  position  of  the  left  and  top  edges  of  the 
page  relative  to  the  left  and  top  edges  respectively  of  the  presentation  medium 
on  which  each  page  is  reproduced.  Any  value  of  page  offset  may  be  specified 
provided  that  no  part  of  the  page  area  lies  outside  the  area  of  the  nominal 
page.  Also,  page  offsets  specified  for  the  initial,  recto  and  verso  pages  within 
a  given  page  set  may  differ.  The  default  page  offset  may  be  specified  in  the 
document  profile. 


6.3.4.5    Page  layout  characteristics 
6.3.4.5.1    General  characteristics 

Each  page  in  a  document  may  be  subdivided  into  three  rectangular  areas,  as 
follows : 

'         a  body  area  which  is  reserved  for  content  that  belongs  to  the  body 
part  of  the  document  ( see  6.3.5); 

a  header  area  which  is  reserved  for  common  header  content  (see 
6.3.6); 

'         a  footer  area  which  is  reserved  for  common  footer  content  (see 
6.3.6) . 

The  body  area  is  mandatory  and  shall  occur  on  every  page  in  a  document.  The 
header  and  footer  areas  are  both  optional. 

Also,  these  three  areas  shall  be  entirely  contained  within  the  page  area  and 
shall  not  overlap. 


Four  types  of  page  layout  are  supported  as  defined  below. 
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6.3.4.5.2    Page  layout  A 

For  page  layout  A  the  header  and  footer  areas  are  placed  above  and  below  the 
body  ctrea  respectively.  The  layout  paths  in  the  header,  body  and  footer  areas 
are  specified  as  270  degrees.  This  type  of  layout  is  illustrated  in  figure  1. 


6.3.4.5.3    Page  layout  B 

For  page  layout  B  the  header  and  footer  areas  are  placed  above  and  below  the 
body  area  respectively.  The  layout  path  in  the  body  eirea  is  specified  as  C 
degrees;  in  the  header  and  footer  areas  the  layout  paths  are  specified  as  270 
degrees.  This  type  of  layout  is  illustrated  in  figure  2. 


6.3.4.5.4  Page  layout  C 

For  page  layout  C  the  header  and  footer  areas  &re  placed  above  and  below  the 
body  area  respectively.  The  layout  path  in  the  body  area  is  specified  as  180 
degrees;  in  the  header  and  footer  areas,  the  layout  paths  are  specified  as  270 
degrees.  This  type  of  layout  is  illustrated  in  figure  3. 

6.3.4.5.5  Page  layout  D 

For  page  layout  D  the  header  and  footer  areas  are  placed  to  the  right  and  left 
of  the  body  airea  respectively.  The  layout  paths  in  the  header,  body  and  footer 
areas  are  all  specified  as  180  degrees.  This  type  of  layout  is  illustrated  in 
figure  4. 
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Figure  1  -  Page  layout  type  A 


Figure  2  -  Page  layout  type  B 
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Figaro  3  -  Pago  layout  typo  C 


Figuro  4  -  Page  layout  type  D 
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(5.3.5    Body  area  characteristica 

6.3.5.1  General  characteristics 

The  body  area  is  the  area  within  a  page  where  the  main  matter  of  the  document, 
that  is  the  'body'  part  of  the  document,  is  laid  out. 

The  body  area  may  consist  of  a  single  frame  into  which  the  content  is  directly 
laid  out.  In  this  case,  the  body  area  is  represented  by  a  BasicBody  frame. 

Alternatively,  the  body  area  is  subdivided  into  different  rectangular  regions  to 
provide  for  combinations  of  single  or  multiple  column  layout  and  the  layout  of 
footnotes.  In  this  case,  the  body  frame  is  represented  by  a 
VariableCompositeBody  frame. 

6.3.5.2  BasicBody 

BasicBody  is  a  constituent  constraint  which  defines  a  l,owest  level  frame  into 
which  content  is  directly  laid  out. 

The  position  and  dimensions  of  this  frame  are  fixed.  The  layout  path  specified 
depends  upon  the  page  layout  type  being  used  (see  6.3.4.5). 

6.3.5.3  VariableCoo^siteBody 

VariableCompositeBody  is  a  constituent  constraint  that  defines  a  composite  frame 
which  contains  one  or  more  subordinate  variably  positioned  frames.  A 
VariableCompositeBody  frame  has  a  fixed  position  and  fixed  dimensions.  The 
layout  path  specified  for  this  frame  depends  upon  the  page  layout  type  being 
used  ( see  6.3.4.5). 

The  immediate  subordinates  of  frames  of  this  type  consist  of  an  arbitreury 
ordered  sequence  of  one  or  more  frames  of  the  following  constituent  constraints ; 

BasicFloat; 

SnakingColumns ; 

SynchronizedColumns 

It  may  also  contain  a  single  frame  of  the  type  FootnoteArea. 

The  subordinate  frames  are  all  variably  positioned  and  have  varisible  dimensions. 
Thus  the  relative  positions  of  these  frames  in  the  body  area  may  vary  and  depend 
upon  the  positions  of  other  frames  (if  any)  that  are  placed  in  the  same 
VariableCompositeBody  frame. 

The  layout  path  for  VariableCompositeBody  frames  may  be  specified  as  270,  0  or 
180  degrees.    This  determines  the  page  layout  type  used  in  the  case  where 
VarialbeCompositeBody  represents  the  entire  body  area. 
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Frames  of  the  type  BasicFloat,  SnakingColumns  and  SynchronizedColumns  are  laid 
out  along  the  layout  path  specified  (in  'normal'  positioning  fill  order). 
FootnoteArea  frames  are  laid  out  in  the  same  direction  as  the  body  area  layout 
path,  but  reverse  fill-  order  is  used. 

These  frames  are  constrained  to  have  the  same  path  as  the  VariableCompositeBody 
frame  to  which  they  are  subordinate.    Except  for  frames  of  the  type 
SnakingColumns . 

Figures  5,  6  and  7  provide  illustrations  of  the  layout  of  frames  within  a 
VjurijUsleCompositeBody  frame  for  the  various  page  layout  types. 

A  choice  of  subordinate  frames  of  the  types  listed  above  may  be  specified  for  a 
VariableCompositeBody  frame.  Different  frame  types  may  be  selected  using  various 
layout  directives  (see  6.4)  and  hence  the  layout  characteristics  of  the  body 
areas  within  a  page  set  may  change  from  page  to  page  within  a  page  set. 

Figure  5  -  Example  of  body  area  layout  for 
page  layout  A 
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Figure  6  -  Bxaa^le  of  body  area  layout  for 
page  layout  B 
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Figure  7  •  Bxaiq>le  of  body  area  layout  for 
page  layouts  C  and  D 
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6.3.5.4  Baa  icFloat 

BasicFloat  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  is 
used  to  represent  a  single  column  area  within  a  body  area.  A  single  column  eirea 
is  typically  used  to  layout  content  in  the  form  of  a  single  column.  This  is  a 
variably  positioned  frame. 

i  The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of 
the  body  area  is  fixed  or  defaults  to  the  maximum  value  allowed  within  the  body 
I  area. 

jlhe  dimensions  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the 
I  body  area  is  specified  as  'Rule-B'.  This  dimension  is  therefore  automatically 
i  adjusted  during  the  layout  process  to  be  the  minimum  required  to  contain  all  the 
content  allocated  to  the  frame . 

I  The  layout  path  specified  for  this  frame  is  the  same  as  that  specified  for  the 
I  body  area,  content  may  only  be  laid  out  in  this  frame  in  the  direction  of  the 
!  layout  path  specified. 

6.3.5.5  SnakingColumns 

!  SnakingColumns  is  a  constituent  constraint  that  defines  a  composite  frame  that 
i I  represents  a  snaking  column  area  within  a  body  area.  A  snaking  column  area  is 
jj  typically  used  for  the  layout  of  one  or  more  columns  of  content  in  which  the 

content  is  allowed  to  flow  freely  from  one  column  to  the  next. 

This  frame  is  variably  positioned.  Its  iimnediate  subordinates  consist  of  one  or 
jimore  frames  of  the  type  ColumnVariable .  Examples  of  the  layout  of  SnakingColumns 
frames  are  given  in  figure  8. 

The  dimension  ef  a  Sr»a,kingColumns  frame  in  the  direction  orthogonal  to  the 
layout  path  of  the  body  area  is  fixed  or  defaults  to  the  maximum  value  allowed 
within  the  body  area. 

The  dimensions  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the 
body  area  is  specified  as  'Rule-B'.  This  dimension  is  therefore  automatically 
adjusted  to  accommodate  the  subordinate  frames  which  are  laid  out  in  it. 

The  layout  path  for  a  SnakingColumns  frame  may  be  specified  as  0  or  180  degrees 
in  the  case  of  page  layout  A,  90  or  270  degrees  in  the  case  of  page  layout  B, 
and  270  degrees  in  the  cases  of  page  layouts  C  and  D. 

The  attribute  "balance"  may  be  specified  for  a  SnakingColumns  frsme  to  indicate 
that  two  or  more  of  the  subordinate  ColumnVariable  frames  aire  to  be 
approximately  equal  in  length  in  the  vertical  dimension  in  the  case  of  page 
layout  A  and  are  to  be  approximately  equal  in  length  in  the  horizontal  dimension 
in  the  cases  of  page  layouts  B,  C  and  D  (see  note).    Note  that  "approximately 
equal"  in  the  context  of  the  "balance"  attribute  means  that  the  leading  edges  of 
the  layout  objects  being  balanced  are  aligned,  as  closely  as  possible,  to  a  line 
orthogonal  to  the  layout  path  for  the  objects. 

NOTE  -  The  attribute  "balance"  may  be  ignored  when  the  subordinate 
ColumnVariedjle  frames  have  unequal  widths. 
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Figure  8  -  Sxan^les  of  the  layout  of  snaJcing  columna 
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6.3.5.6  SynchronlzedColumns 

I  SynchronizedColumns  is  a  constituent  constraint  that  defines  a  composite  frame 
that  represents  a  synchronized  columns  area  within  a  body  area.  A  synchronized 
i  columns  area  is  typically  used  to  represent  one  or  more  columns  of  content  such 
!  that  the  content  laid  out  in  each  column  belongs  to  different  layout  streams. 
I  Thus  content  laid  out  in  one  column  is  not  allowed  to  flow  into  the  next  column. 

I  This  type  of  colxomn  layout  is  typically  used  when  it  is  required  to  layout 
i  separate  eimounts  of  content  in  parallel  with  one  another  such  that  they  are 
;  aligned.  Examples  axQ  the  synchronized  layout  of  content  belonging  to  different 
j  languages  and  the  layout  of  a  figure  in  peirallel  with  some  text.  An  example  is 
shown  in  figure  9 . 

I  With  regard  to  positioning  and  dimensioning,  SynchronizedColumns  frames  have  the 
I  same  characteristics  as  SnakingColumns  freunes. 

i  The  immediate  subordinates  of  a  SynchronizedColumns  frame  consist  of  any  number 

t  of  frames  of  the  type  ColumnFixed. 

[  ^ 

■  The  layout  path  for  a  SynchronizedColumns  frame  is  27  0  degrees  for  page  layout 
I  A,  0  degrees  for  page  layout  B  and  180  degrees  for  page  layouts  C  and  D. 


Figure  9  -  Example  of  synchronized  column  layout 
for  page  layout  A 
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6.3.5.7  ColumnVariable 

ColumnVarifible  is  a  constituent  constraint  that  defines  a  lowest  level  frame 
that  is  used  to  represents  a  column  of  content  within  a  snakingColumns  frame. 
This  is  a  frame  which  is  variably  positioned. 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  | 
superior  SnakingColumns  frame  (that  is,  the  column  width)  is  fixed.  The 
dimensions  of  different  instances  of  ColumnVariable  frames  within  a  given 
SnakingColumns  frame  may  differ  to  allow  columns  of  different  widths  to  be 
specified. 

The  dimension  in  the  direction  orthogonal  to  the  layout  path  of  the  superior 
frame  (that  is,  the  column  length)  may  be  specified  as  'Rule-B'  or  'maximum- 
size'. 

The  layout  path  for  ColumnVariable  frames  is  270  degrees  in  the  case  of  page 
layout  A,  0  degrees  in  page  layout  B  and  180  degrees  in  page  layouts  C  and  0. 

\ 

All  ColumnVariable  frames  subordinate  to  the  same  SnakingColumns  frame  shaJ.!  | 
have  the  same  category  name;  different  names  may  be  used  for  ColumnVarieible 
frames  laid  out  in  different  SnakingColumns  frames.  ^ 

3 

6.3.5.8  ColumnFized 

M 

ColumnFixed  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that  f 
is  used  to  represent  a  column  of  content  within  a  Synchronizedcolumns  frame. 
This  is  a  frame  which  has  a  fixed  position. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of  { 
the  superior  Synchronizedcolumns  frame  (that  is,  the  column  width)  may  be  fixed 
or  specified  as  'maximum  size'  (see  note)  in  all  page  layout  types.  This 
dimension  may  differ  for  different  instances  of  ColumnFixed  frames  within  a 
given  Synchronizedcolumns  frame  to  allow  columns  of  different  widths  to  be 
specified.  However,  the  widths  shall  be  specified  such  that  the  columns  do  not 
overlap .  |! 

The  dimension  of  this  frame  in  the  direction  parallel  to  the  layout  path  of  the  ^ 
superior  frame  (that  is,  the  column  length)  may  be  specified  as  'Rule-B'  or  j 
'maximum-size'  in  the  cases  of  page  layouts  A  and  B.  In  the  cases  of  page  ! 
layouts  C  and  D,  this  dimension  may  only  be  specified  as  'maximum-size'.  i 

The  ColumnFixed  frames  subordinate  to  a  given  synchronizedcolumns  frame  shall  r 
have  different  category  names.  1 

The  layout  path  for  ColumnFixed  frames  shall  be  equal  to  the  layout  path  of  the  ' 
superior  Synchronizedcolumns  frame. 

The  content  laid  out  in  different  ColumnFixed  frames  within  the  same 
Synchronizedcolumns  frame  may  be  specified  as  'synchronized'  by  using  the  ^ 
attribute  "synchronization". 
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NOTE  -  The  value  'maximum  size'  may  only  be  specified  for  the  right  most 
ColumnFixed  frames  (relative  to  the  page  co-ordinate  system)  laid  out  in  a 
SynchronizedColumns  frame,  to  prevent  overlapping  of  the  frames. 

6.3.5.9  FootnoteArea 

FootnoteArea  is  a  constituent  constraint  that  defines  a  lowest  level  frame  that 
is  used  to  represent  a  footnote  area  within  a  body  area..  A  footnote  area  is 
typically  used  for  the  layout  of  footnotes. 

Frames  of  this  type  are  variably  positioned  with  a  positioning  fill  order 
specified  as  'reverse'.  Hence  this  frame  is  positioned  adjacent  to  the  leading 
edge  of  the  VariableCompositeBody  frame. 

The  dimension  of  FootnoteArea  frames  in  the  direction  orthogonal  to  the  layout 
path  of  its  superior  frame  is  fixed  or  specified  as  'maximum  size ' .  in  the 
direction  of  the  layout  path,  the  dimension  is  specified  by  'Rule-B'  which  means 
that  this  dimension  is  automatically  adjusted  to  contain  all  the  content  that  is 
allocated  to  it.  . 

The  layout  path  for  FootnoteArea  frames  is  the  same  as  that  specified  for  the 
body  area. 

The  content  that  may  be  laid  out  in  this  frame  is  limited  to  the  content  that  is 
associated  with  basic  logical  objects  which  are  subordinates  of  the  composite 
logical  object  'FootnoteBody .    To  achieve  this,  the  permitted  categories 
attribute  of  this  frame  shall  specify  the  category  'Footnote',  the  same  name 
required  on  the  basic  logical  objects  for  footnotes  (see  6.2.3.10  and  6.2.3.11). 

€.3.6    Header  and  footer  area  characteristics 

6.3.6.1    General  characteristics 

The  header  and  footer  areas  consist  of  either  basic  areas  or  composite  areas. 

A  basic  header  or  footer  area  is  an  area  into  which  the  content  is  directly  laid 
out.  This  type  of  area  is  represented  by  a  constituent  constraint  of  the  type 
BaaicHeader  or  BasicFooter  respectively. 

A  composite  header  or  footer  area  is  an  area  which  is  subdivided  into  separate 
sourced  content  and  arranged  content  areas  to  provide  greater  versatility  with 
regard  to  the  layout  of  the  content.    This  type  of  area  is  represented  by  a 
constituent  constraint  of  the  type  compos iteHeader  or  compos iteFooter 
respectively. 

In  the  case  of  basic  header  or  footer  areas,  the  content  allocated  to  these 
areas  is  derived  from  the  common  part  of  the  logical  structure  of  a  document.  In 
the  case  of  composite  header  or  footer  areas,  the  content  may  again  be  derived 
from  the  common  part  of  the  logical  structure  of  a  document  but  the  content  may 
also  be  derived  from  common  content  specified  in  the  generic  layout  structure. 
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6.3.6.2    BasicHeader  and  BasicFooter 

BasicHeader  and  Basic  Footer  are  constituent  constraints  that  define  lowest 
level  frames  that  represent  areas  within  a  page  that  are  reserved  for  common 
content . 

These  types  of  frame  have  fixed  positions  and  dimensions.  The  positioning  of 
these  friunes  within  a  page  and  the  layout  paths  that  may  be  specified  for  them 
depends  upon  the  page  layout  type  used  (see  6.3.4.5) 

The  content  that  is  laid  out  in  these  frames  is  derived,  using  the  logical 
source  mechanism,  from  the  content  associated  with  the  composite  logical  object 
classes  of  the  type  CommonContent . 


6.3.6.3  Con^xisiteHeader  and  CoiiqxDsiteFooter 

CompositeHeader  and  Compos iteFooter  are  constituent  constraints  that  define 
composite  frames  that  represent  areas  within  a  page  that  are  reserved  for  common 
content. 

These  types  of  frame  have  fixed  positions  and  dimensions.  The  positioning  of 
these  frames  within  a  page  and  the  layout  path  that  may  be  specified  for  them 
depends  upon  the  page  layout  type  used  ( see  6.3.4.5) 

The  subordinates  of  these  frames  may  consist  of  either: 

a)  any  number  and  combination  of  variably  positioned  frames  of  the  types 
SourcedContentVariable  and  ArrangedContentVaricible . 

or 

b)  any  nvunber  and  combination  of  fixed  positioned  frames  of  the  types 
SourcedContentFixed  and  ArrangedContentFixed. 

In  case  b),  the  subordinate  frames  may  overlap  without  restriction. 

6.3.6.4  SourcedContentVciricLble 

A  Sourcedcontentvaricible  frame  is  a  constituent  constraint  that  defines  a  lowest 
level  frame  that  represents  a  region  within  a  header  footer  area  that  contains 
common  content  derived  from  the  generic  logical  structure.  This  frame  is 
variably  positioned  and  its  layout  path  is  the  same  as  that  of  the  containing 
header  or  footer  area. 

The  dimension  of  this  frame  in  the  direction  orthogonal  to  the  layout  path  of 
the  superior  frame  is  fixed  or  specified  as  'maximum-size'.    The  dimensions  of 
the  frame  in  the  direction  parallel  to  the  layout  path  of  the  superior  frame  is 
specified  as  either  fixed  or  'Rule-B'. 
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This  frame  is  required  to  specify  the  attribute  "logical  source"  which  indicates 
the  particular  instance  of  the  constituent  constraint  CoonnonContent  which 
contains  the  content  to  be  laid  out  in  this  frame. 

Typically,  this  frame  is  used  for  the  positioning  of  content  which  is  generated 
during  the  layout  process,  such  as  a  character  sequence  containing  a  page 
number. 


6.3.6.5  ArrangedContentVar labia 

An  ArrangedContentVari2d3le  frame  is  a  constituent  constraint  that  defines  a 
lowest  level  frame  that  represents  a  region  within  a  header  or  footer  area  that 
contains  pre-defined  common  content  contained  in  the  generic  layout  structure, 
i  This  frame  is  variably  positioned  and  its  dimensions  are  fixed. 

1  This  frame  references  one  or  more  blocks  of  type  GenericBlock  (see  6.3.7)  which 
I  contain  the  content  to  be  laid  out  in  this  frame.  Thus,  this  frame  is  typically 

j  used  when  it  is  required  to  layout  pre -determined  common  content. 

i 

^  * 

6.3.6.6  SourcedContentFixed 

A  SourcedContentFixed  frame  is  a  constituent  constraint  that  defines  a  lowest 
level  frame  that  represents  a  region  within  a  header  footer  area  that  contains 

I  common  content  derived  from  the  generic  logical  structure.  This  frame  has  a 
fixed  position  and  dimensions  and  its  layout  path  is  equal  to  that  of  the 
containing  header  or  footer  area. 

This  frame  is  required  to  specify  the  attribute  "logical  source"  which  indicates 
the  peorticular  instance  of  the  constituent  constraint  CommonContent  which 
contains  the  content  to  be  laid  out  in  this  frame. 

Thus,  as  in  the  case  of  SourcedContentVariable  frames,  this  frame  is  used  for 
the  positioning  of  content  which  is  generated  during  the  layout  process,  such  as 

II  a  cheuracter  sequence  containing  a  page  nvimber. 

i 

'I  6.3.6.7  ArrangedContentFixed 

I  An  ArrangedContentFixed  frame  is  a  constituent  constraint  that  defines  a  lowest 
level  frame  that  represents  a  region  within  a  header  or  footer  area  that 
contains  pre-defined  common  content  derived  from  the  generic  layout  structure. 
The  position  and  dimensions  of  this  frame  are  fixed.    This  frame  references  one 
or  blocks  of  type  GenericBlock  (see  6.3.7)  which  contain  the  content  to  be  laid 
out  in  this  frame.  Thus  this  frame  is  typically  used  when  it  is  required  to 
layout  common  content  at  pre-determined  positions  in  the  header  or  footer  areas. 


I 

1 
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6.3.7    GenericBlock  and  Specif icBlock 

Two  types  of  constituent  constraints  of  the  type  'block'  are  defined,  namely 
GenericBlock  and  specif icBlock. 

object  classes  of  the  type  GenericBlock  nay  occur  in  the  generic  layout 
structure  referenced  by  the  "generator  for  subordinates"  of  object  classes  of 
the  types  ArrangedcontentVariable  and  ArrangedContentFixed.  When  the  layout 
process  is  performed  to  produce  a  document  in  formatted  processable  form, 
equivalent  blocks  may  occur  in  the  specific  layout  structure.  Objects  of  this 
type  are  restricted  to  occur  within  the  header  and  footer  areas  of  the  page. 

objects  of  the  type  specificBlock  may  only  occur  in  the  specific  layout 
structure.  They  are  created  during  the  document  layout  process  and  result  from 
the  layout  of  basic  logical  objects  into  lowest  level  frames  that  constitute  the 
body,  header  and  footer  areas. 


6.4    Document  layout  characteristics 

Mechanisms  for  controlling  the  allocation  of  logical  constituents  to  various 
areas  in  the  layout  structure  are  defined  in  6.4.1.  Mechanisms  for  controlling 
the  layout  of  the  content  within  the  allocated  areas  are  defined  in  6.4.2. 

These  mechanisms  relate  to  documents  for  which  a  generic  layout  structure  is 
specified.  When  a  generic  layout  structure  is  not  present,  then  these  aiechanisms 
are  restricted  as  described  in  6.4.3. 


6.4.1    Flow  controls 

Vsurious  mechanisms  are  provided  to  control  the  allocation  of  constituent 
constraints  representing  the  'body  parts  of  the  logical  structure  of  a  document 
to  pages  sets,  pages  and  body  areas.  These  are  described  in  6.4.1.1,  6.4.1.2  and 
6.4.1.3.  The  mechanisms  for  controlling  the  layout  of  the  'common'  parts  of  a 
document  are  described  in  6.4.1.4. 


6.4.1.1    Allocation  of  content  to  page  sets 

Two  methods  of  allocating  the  constituent  constraints  associated  with  the  'body' 
part  of  the  document  to  page  sets  are  provided: 

a)  Layout  in  a  nominated  page  set; 

b)  Starting  a  new  page  set. 

The  first  method  provides  the  ability  to  specify  that  a  part  of  a  document  is  to 
be  laid  out  entirely  within  a  specified  page  set.  This  may  be  specified  for 
constituent  constraints  of  the  types  Passage,  NmnberedSegment  and  Paragraph 
using  the  attribute  "layout  object  class"  which  specifies  the  object  class 
identifier  of  the  required  class  of  page  set. 
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The  second  method  provides  the  ability  to  specify  that  the  logical  objects 
derived  from  a  particular  logical  constituent  constraint  in  a  document  and  all 
subsequent  parts  of  a  document  are  to  be  laid  out  starting  at  the  beginning  of  a 
new  page  set.  This  may  be  specified  for  the  following  logical  constituent 
constraints : 

-  Passage; 

-  NumberedSegment; 

-  Paragraph; 

-  Number; 

-  BodyText; 

-  BodyRaster;  , 

-  BodyGeometric . 

This  is  achieved  using  the  attribute  "new  layout  object"  which  specifies  the 
object  class  identifier  of  the  required  class  of  page  set. 

6.4.1.2    Page  breaks 

This  provides  the  {Utility  to  specify  that  the  logical  objects  derived  from  a 
particular  logical  constituent  constraint  in  a  document  and  all  subsequent  parts 
of  a  document  are  to  be  laid  out  staurting  at  the  beginning  of  a  new  page.  The 
page  specified  shall  belong  to  the  page  set  in  which  the  logical  objects  from 
the  immediately  preceding  logical  constituent  constraint  is  laid  out  (see  note). 

This  may  be  specified  for  the  following  logical  constituent  constraints: 

-  Passage;  « 

-  NumberedSegment; 
I          -  Paragraph; 

-  Number; 

I  ■ 

-  BodyText; 

-  BodyRaster; 

-  BodyGeometric. 

I 
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This  is  achieved  using  the  attribute  "new  layout  object" .  This  attribute  may 
specify  the  value  'page'  indicating  that  the  logical  constituent  constraint  is 
to  be  laid  out  starting  on  the  next  availaible  page  which  may  be  of  any  class. 
Alternatively,  the  attribute  may  specify  that  the  logical  constituent  constraint! 
is  to  be  laid  out  steLrting  on  a  page  of  a  particular  class;  this  is  achieved  by 
specifying  the  object  class  identifier  of  the  required  page  class. 

NOTE  -  The  specification  of  a  page  break  shall  not  be  used  to  layout  part  ' 
of  a  document  in  a  new  page  set.  If  a  new  page  set  is  required,  then  this  I 
shall  be  explicitly  specified  as  described  in  6.4.1.1. 

6.4.1.3    Allocation  of  content  to  body  areas 

If  the  page  to  which  the  content  is  allocated  contains  a  basic  body  area.,  then 
the  content  is  laid  out  in  sequential  order  in  that  body  area  in  the  form  of  a 
single  column. 

If  the  page  contains  a  composite  body  area,  then  the  content  is  allocated  to 
single,  snaking  and  synchronized  columns  areas  and  footnote  areas  as  described 
below. 


6.4.1.3.1    Layout  of  content  into  column  areas 

When  laying  out  content  into  a  composite  body  area  having  more  than  one 
subordinate  frame  class  (excluding  FootnoteArea  frame  classes),  it  is  necessary 
to  indicate  which  of  the  column  areas  is  to  be  used. 

Logical  objects  of  the  types  Paragraph,  Number,  FootnoteReference,  BodyText, 
BodyRaster  and  BodyGeometric  may  be  specified  to  be  laid  out  in  instances  of  one 
or  more  single  columns  area,  snaking  columns  area  or  synchronized  columns  area. 
This  is  done  by  giving  each  such  basic  logical  component  a  value  of  the 
attribute  'layout-category'  which  corresponds  to  the  value  of  the  attribute 
'permitted-categories '  which  applies  to  the  lowest  level  of  frame  in  which  the 
content  is  to  be  laid  out. 

Note  that  any  basic  logical  objects  in  the  specific  logical  structure  to  which 
this  attribute  does  not  apply  will  be  laid  out  only  in  a  lowest  level  frame 
which  has  the  implicit  value  of  the  attribute  'permitted-categories'. 

The  use  of  layout  categories  ensures  that  if  there  is  insufficient  area  on  one 
page  to  lay  out  all  of  the  content  allocated  to  a  particular  type  of  area,  then 
the  laying  out  of  the  content  will  automatically  continue  in  the  same  type  of 
area  in  a  succeeding  page.  Thus  content  is  allowed  to  flow  freely  from  one  page 
to  the  next  when  the  type  of  layout  used  at  the  end  of  one  page  is  the  same  as 
that  at  the  beginning  of  the  succeeding  page. 
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It  is  necessary  to  ensure  the  correct  use  of  the  mechanism  for  the  layout  of 
ihdependent  layout  streams.     In  the  absence  of  additional  layout  directives, 
content  may  be  placed  in  available  space  within  an  earlier  frame  of  the 
specified  'permitted-categories ' .     If  this  is  not  intended,  it  may  be  prevented 
by  the  use  of  the  attribute  ' new-layout -ob ject ' . 

The  attribute  'new-layout -object'  may  be  applied  to  logical  components  of  the 
types  NumberedSegment,  Paragraph,  Number,  FootnoteRef erence,  BodyText, 
BodyRaster  and  BodyGeometric ,  whenever  a  change  in  column  layout  is  required. 

The  attribute  "new  layout  object"  may  specify  the  identifier  of  the  frame  class 
that  represents  the  single,  snaking  or  synchronized  column  area  required.  In  the 
case  of  single  or  synchronised  column  5u:eas,  the  attribute  "new  layout  object" 
nay  indicate  the  category  name  corresponding  to  the  frame  class  of  the  single 
coluom  area  or  of  any  of  the  colimns  within  the  synchronised  column  area  that  is 
required . 

When  layout  occurs  in  a  snaking  columns  area,  column  breaks  may  be  indicated  by 
using  the  attribute  "new  layout  object".  This  attribute  may  specify  the 
identifier  or  the  category  name  of  the  frame  corresponding  to  the  column  in 
which  the  layout  is  to  continue.     However  only  the  use  of  a  category  name  will 
ensure  that  a  single  column  break  is  always  obtained,  irrespective  of  the  frame 
class  actually  used. 

When  the  layout  is  to  occur  in  a  synchronized  columns  area,  category  names  are 
used  to  control  the  particular  columns  that  are  to  be  used  to  layout  the  logical 
entities.  Each  column  within  a  synchronized  columns  area  shall  have  a  different 
permitted  category  and  each  basic  logical  entity  to  be  laid  out  in  this 
particular  area  shall  have  a  category  name  corresponding  to  a  name  allocated  to 
j  one  of  the  columns.  The  logical  entities  allocated  to  different  columns  may  be 
aligned  using  the  attribute  "synchronization". 

6.4.1.3.2    Layout  of  footnotes 

I  The  logical  objects  derived  from  basic  logical  constituent  constraints  that 
I  represent  the  content  belonging  to  a  footnote  (i.e  FootnoteNumber  and 
j  FootnoteText )  are  constrained  to  be  laid  out  in  a  footnote  area  which  is 
represented  by  a  FootnoteArea  frame  ( see  6.3.5.9). 

This  constraint  is  specified  by  means  of  category  names.  That  is,  the  logical 
constituents  of  the  types  FootnoteNxunber  and  FootnoteText  and  layout 
1   constituents  of  the  type  FootnoteArea  are  all  required  to  have  the  category  name 
'Footnote' . 

!   More  than  one  footnote  may  be  placed  in  a  footnote  area  within  a  given  body 
j   area.  In  this  case  the  content  belonging  to  the  footnotes  are  laid  out 
sequentially  in  the  footnote  area  in  accordance  with  their  reading  order. 

If  the  content  belonging  to  a  footnote  cannot  all  be  accommodated  in  the 
I    footnote  area  on  one  page,  then  the  content  may  freely  flow  into  the  footnote 
j    airea  on  the  next  page.  Alternatively,  it  is  possible  to  specify  that  a  footnote 
i    is  to  be  laid  out  entirely  within  a  particular  footnote  area.  This  is  achieved 
using  the  attribute  "indivisibility". 


39 


FOD26  Part  1  -  Doctunent  Application  Profile  JUly  1992  u 


6.4.1.4    Allocation  of  content  to  header-footer  areas 

h  header  or  footer  area  nay  be  basic  or  composite  (see  6.3.6.1).  In  the  case  of 
a  basic  area,  the  frame  representing  that  area  specifies  the  attribute  "Logical 
source"  which  indicates  the  particular  instance  of  the  constituent  constraint  of 
the  type  Commoncontent  that  is  to  be  laid  out  in  that  area.  The  basic  logical 
constituents  subordinate  to  Commoncontent  are  then  laid  out  in  accordance  with 
their  sequential  order. 

In  the  case  of  a  composite  header  or  footer  area  (see  6.3.6.3),  the  area  is 
divided  into  one  or  more  separate  areas,  each  of  which  is  represented  by  a 
lowest  level  frame.  The  content  allocated  to  the  separate  aze&B  nay  be  derived 
from  one  of  two  sources.  That  is,  the  content  nay  be  pre-defined  and  represented 
by  one  or  more  blocks  which  are  directly  associated  with  the  lowest  level  frame. 
Alternatively,  the  lowest  level  frame  nay  specify  the  attribute  "logical  source" 
which,  as  above,  indicates  the  particular  logical  object  of  the  type 
Commoncontent  that  is  to  be  laid  out  in  that  frame. 


6.4.2    Layout  of  the  document  content 

Various  constraints  nay  be  specified  to  control  the  layout  of  the  content  into 
the  body,  header  and  footer  areas.  These  constraints  ars  described  below. 


6.4.2.1    Margins  | 

The  margins  are  the  minimum  distances,  or  offsets,  between  a  part  of  the  i 
document  content  and  the  edge  of  the  particular  area  in  which  that  content  is 
laid  out.  The  margins  define  the  maximum  extents  of  the  available  area  into  i 
which  the  content  shall  be  positioned.  | 

Margins  nay  be  specified  for  any  constituent  constraint  representing  a  basic  i 
logical  object;  different  meurgin  values  nay  be  specified  for  different 
constituent  constraints  without  restriction. 

Four  margins  may  be  independently  specified  for  each  constituent  constraint, 
namely: 

-  trailing  edge  margin; 

-  leading  edge  margin; 
right  hand  edge  margin; 

-  left  hand  edge  margin. 

These  margins  are  defined  in  relationship  to  the  layout  path  specified  for  the 
frame  in  which  the  content  is  to  be  laid  out  in  (see  Figure  10). 
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Any  combination  of  the  above  margins  may  be  specified  for  a  pjurticular 
Constituent  constraint.  These  margins  are  specified  by  the  attribute  "offset". 
Any  value  may  be  specified  in  units  of  BMUs.  If  a  particuleur  margin  is  not 
specified,  then  it  is  assiuned  to  be  0  BHUs. 


6.4.2.2  Separation 

Leading  separations  is  the  minimum  distance  between  one  basic  logical  object  and 
the  next  one,  if  any,  when  they  are  laid  out;  trailing  separation  is  the  minimum 
j  distance  between  one  basic  logical  object  and  the  previous  one,  if  any,  when 
;  they  are  laid  out.    Both  may  be  specified  for  basic  logical  components  of  any 
I  constituent  constraint  types.    These  distances  are  specified  in  BMUs  by  the 
j  attribute  "separation".    If  no  value  is  specified,  then  the  minimum  distance  is 
j  assumed  to  be  0  BMUs. 

I  6.4.2.3  Indivisibility 

I  Indivisibility  provides  the  means  to  specify  whether  or  not  a  logical  object 
I  derived  from  a  basic  or  composite  logical  constituent  constraint  is  allowed  to 

be  split  over  more  than  one  page  or  over  more  than  one  area  within  a  page.  It 
I  may  be  specified  for  constituent  constraints  of  the  types  Passage, 
I  Numberedsegment,  Peuragraph,  Footnote,  Number,  FootnoteReference  and  BodyText. 
I  The  attribute  "indivisibility"  is  used  to  specify  this  feature. 


I  6.4.2.4    Sana  layout  object 

1  Sane  layout  object  provides  the  means  to  specify  that  the  start  of  the  content 
i|  associated  with  a  logical  object  and  the  end  of  the  content  associated  with  the 

previous  logical  object  are  to  be  laid  out  within  a  single  layout  object.  This 
j  nay  be  specified  for  logical  objects  of  the  types  Numberedsegment,  Paragraph, 

Number,  Footnote,  FootnoteReference,  BodyText,  BodyRaster  and  BodyGeometric . 

The  attribute  "same  layout  object"  is  used  to  specify  this  feature. 
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6.4.2.5  Concatenation 

Concatenation  provides  the  means  to  specify  that  the  content  associated  with  a 
logical  object  derived  from  a  basic  logical  constituent  constraint  and  the 
content  associated  with  the  logical  object  derived  from  previous  basic  logical 
constituent  constraint  are  to  be  regarded  as  an  unbroken  stream  of  content.  This 
may  be  specified  for  constituent  constraints  of  the  types  BodyText,  Number, 
FootnoteReference,  FootnoteText,  CommonText  and  PageNximber.  The  attribute 
"concatenation"  is  used  to  specify  this  feature. 

6.4.2.6  Block  alignment 

Block  alignment  allows  the  content  associated  with  a  basic  logical  entity  to  be 
specified  as  'left  aligned',   'right  aligned'  or  'centred'  within  the  area  in 
which  that  content  is  laid  out.  Left  aligned  means  that  the  content  is  laid  out 
adjacent  to  the  left  hand  edge  margin.  Right  aligned  means  that  the  content  is 
laid  out  adjacent  to  the  right  hand  edge  margin  and  centred  means  that  the 
content  is  laid  out  midway  between  the  left  and  right  meurgins. 
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This  feature  may  only  be  specified  using  the  attribute  "block  alignment"  for 
constituent  constraints  of  the  types  Number,  FootnoteRef erence,  FootnoteText, 
PageNumber,  FootnoteNumber ,  BodyText  and  CommonText ,  when  they  contain  formatted 
character  content,  BodyRaster,  and  BodyGeometric ,  CommonRaster  and 
ConononGeometric . 

6.4.3    Layout  controls  applicable  in  the  absence  of  a  generic  layout  structure 

In  processedale  form  documents  the  generic  layout  structure  is  optional.  If  the 
generic  layout  structure  is  omitted,  then  it  is  the  responsibility  of  the 
receiver  to  define  an  appropriate  layout  structure.  No  limitations  are  placed  on 
the  layout  structure  that  is  used. 

j  When  a  generic  layout  structure  is  not  specified  within  a  processable  form 
i  document,  then  restrictions  are  placed  on  the  layout  control  functions  described 
j  in  6.4.1  and  6.4.2  that  may  be  specified  within  the  document.  These  restrictions 
!  are  indicated  below. 

a)  It  is  not  possible  to  specify  that  certain  logical  parts  of  a 
document  are  to  be  allocated  to  a  given  page  set  or  that  a  part  of  a 

I  document  is  to  be  laid  out  starting  in  a  new  page  set,  as  defined  in 

6.4.1.1. 

b)  It  is  possible  to  specify  page  breaks  as  defined  in  6.4.1.2  but  it  is 
,                     only  possible  to  indicate  that  the  layout  shall  begin  on  a  new  page. 

I  It  is  not  possible  to  specify  a  particular  page  class. 

c)  The  logical  parts  of  the  dociament  that  are  intended  to  be  laid  out  in 
the  body  area  and  in  the  header/footer  areas  of  each  page  may  be 
distinguished  from  each  other  by  means  of  application  comments 
specified  for  them  (see  6.6.4).  An  exception  is  that  it  is  not 
possible  to  distinguish  whether  a  particular  portion  of  the  common 

ij  content  is  to  be  placed  in  a  header  or  footer  area  (or  both). 

1  d)        It  is  not  possible  to  indicate  the  type  of  layout  area  to  be  used  to 

layout  each  logical  constituent  in  the  body  part  of  a  docximent.  That 
ij  is,  it  is  not  possible  to  indicate  whether  single  column  or  multiple 

!'l  column  areas  are  to  be  used  (see  6.4.1.3.1).  This  shall  be  decided  by 

the  receiver. 


e)  Footnotes  within  the  body  part  of  a  document  may  be  distinguished  by 
use  of  the  attribute  "application  comments".  Footnotes  are  intended 
to  be  read  and  laid  out  separately  from  the  other  logical 
constituents  of  the  body  part  (see  6.4.1.3.2).  However,  it  is  the 
responsibility  of  the  receiver  to  decide  how  footnotes  are  laid  out. 

f)  Margins,  separation,  indivisibility,  same  layout  object, 
concatenation,  and  block  alignment,  as  defined  in  6.4.2  may  all  be 
specified.  Only  one  restriction  applies.  Indivisibility  (see  6.4.2.3) 
may  be  assumed  to  specify  that  a  logical  constituent  constraint  is 
not  to  split  over  more  than  one  page  but  indivisibility  shall  not  be 
specified  for  other  types  of  layout  areas  such  as  single  or  multiple 
column  areas . 
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6.5    Content  layout  and  uiaging  characteristics 

A  document  nay  contain  character,  raster  graphics  and  geometric  graphics 
content . 

The  content  architectures  that  may  be  specified  using  the  attribute  "content 
architecture  class"  are  formatted  character,  processable  cheuracter,  formatted 
processable  character,  formatted  processable  raster  graphics  and  formatted 
processable  geometric  graphics.  Any  of  these  may  be  specified  as  the  default  in 
the  document  profile. 

I 

6.5.1    Character  content  I 


6.5.1.1  Introduction 

This  subclause  defines  the  features  that  are  applicable  to  the  character  content 
contained  in  a  dociiment  and  the  presentation  attributes  and  control  functions 
that  may  be  used  to  specify  these  features.  These  features  may  apply  to  basic 
logical  and  layout  components  unless  otherwise  indicated. 

The  default  values  for  the  following  features  may  be  specified  in  the  document 
profile: 

graphic  character  sets; 

graphic  chsuracter  subrepertoire; 

code  extension  announcers; 

-  line  spacing; 
character  spacing; 

character  path;  [| 

-  line  progression; 

-  character  orientation;  ^ 

i 

graphic  rendition,  including  the  parameters  values:  ^ 
default  rendition,  increased  intensity  (bold),  italicised, 
underlined,  crossed  out,  primeury  font,  1st  alternative  font,  2nd 
alternative  font,  3rd  alternative  font,  4th  alternative  font,  5th 
alternative  font,  6th  alternative  font,  7th  alternative  font,  8th 
alternative  font,  9th  alternative  font,  doubly  underlined,  normal 
intensity,  not  italicised,  not  underlined,  not  crossed  out; 

i 
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line  layout  table; 

-  indentation; 
alignment; 

-  first  line  offset; 

-  itemization; 

-  widow  size; 

-  orphan  size; 
character  fonts; 

-  kerning  offset; 
proportional  line  spacing; 
initial  offset. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation 
attribute  or  control  function  shall  be  indicated  in  the  document  profile. 

I  6.5.1.2    Character  content  architecture  class 

Processeible  and  formatted  processable  form  documents  may  contain  processable, 
formatted  or  formatted  processaJale  character  content.  Formatted  form  documents 
I  may  contain  formatted  and  formatted  processable  character  content. 

1  When  using  character  content,  any  number  of  content  portions  may  be  associated 
with  a  basic  component. 

The  content  information  in  a  content  portion  may  be  absent.  This  is  to  allow  the 
representation  and  interchange  of  documents  in  which  parts  of  the  content  may  be 
supplied,  for  example,  during  subsequent  editing. 

I  6.5.1.3    Character  repertoires 

i' 

The  basic  character  repertoire  supported  by  this  profile  is  composed  of  the  94 
cheuracters  of  IS0-IR6  (the  IRV  of  ISO  646  revised  1991)  plus  the  character 
I  space . 

Any  other  graphic  character  set  which  is  registered  in  accordance  with  ISO  2375 
taay  be  designated  and  invoked  at  any  point  in  the  document  provided  its  use  is 
indicated  in  the  document  profile  as  a  non-basic  value  using  the  cheoracter 
presentation  feature  "graphic  character  sets".  No  locking  shift  functions  are 
specified  in  this  presentation  feature. 

|!  The  code  extension  techniques  allowed  for  the  designation  and  invocation  of 
character  sets  to  the  left  hand  side  and  right  hand  side  of  the  8-bit  code  table 
(GL  and  GR  respectively)  are  defined  in  6.5.1.4. 
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Using  these  code  extension  techniques,  the  graphic  character  sets  designated 
and/or  invoked  at  the  beginning  of  a  content  portion  containing  character 
content  are  specified  by  the  presentation  attribute  "graphic  character  sets". 
The  graphic  character  sets  may  also  be  changed  at  any  point  within  a  content 
portion . 

The  default  graphic  character  sets  which  apply  to  the  content  portions  within  a 
document  may  be  specified  in  the  document  profile  using  the  presentation 
attribute  "graphic  character  sets". 

If  the  character  set  defined  in  ISO  6937-2  with  or  without  Addendum  1  is 
designated  and  invoked,  then  the  use  of  any  of  its  subrepertoires  registered 
according  to  ISO  7350  may  be  specified  using  the  presentation  attribute  "graphic 
character  subrepertoire" .  All  sub-repertoires  are  non-basic  and  their  use  shall 
be  indicated  in  the  document  profile.  The  subrepertoire  shall  not  be  changed 
within  a  content  portion. 

NOTES 

1;        The  basic  character  repertoire  supported  by  this  profile  is  not  the 
standard  default  value  specified  in  [ISO  8613-6 |cciTT  Recommendation 
T.416];  hence  it  may  be  necessary  to  specify,  in  the  document  profile 
of  a  particular  document,  that  this  is  the  default  value  being  used 
for  that  document. 

2:        Revised  CCITT  Recommendations  T.50  and  T.51  and  new  CCITT 

Recommendation  T.52  are  under  preparation.  CCITT  Recommendations  T.50 
and  T.51  are  intended  to  be  completely  compatible  with  ISO  646 
revised  1991  (ISO  IR-6)  and  ISO  6937  (under  revision)  respectively. 


6.5.1.4    Code  extension  technic[uea 

The  code  extension  techniques  specified  in  ISO  2022  may  be  used  subject  to  the 
following  restrictions: 

i)  GO  set:  only  IS0-IR6  (the  IRV  of  ISO  646  revised  1991),  IS0-IR2  (the 
primary  set  of  ISO  6937-2),  or  any  other  version  of  ISO  646  may  be 
designated  for  this  set;  these  graphic  character  sets  may  only  be 
invoked  in  GL. 

ii)  Gl,  G2,  G3  sets:  no  restrictions  axe  placed  on  the  character  sets 
that  may  be  designated  for  these  sets;  these  graphic  character  sets 
may  only  be  invoked  in  GR. 

iii)  The  locking  and  single  shift  functions  allowed  are  as  follows: 

-  LSO  to  invoke  the  GO  set  into  GL; 

-  LSlR  to  invoke  the  Gl  set  into  GR; 

-  LS2R  to  invoke  the  G2  set  into  GR; 

-  LS3R  to  invoke  the  G3  set  into  GR; 

-  SS2  to  invoke  one  character  from  the  G2  set  into  GL; 

-  SS3  to  invoke  one  character  from  the  G3  set  into  GL. 


(Here  GL  and  GR  refer  to  the  left  and  right  hand  parts  respectively 
of  the  8-bit  code  table) 
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iv)      when  specifying  the  presentation  attribute  "graphic  character  sets'*, 
it  is  necesscuiry  to  invoke  cheoracter  sets  for  both  GL  and  GR.  Thus  an 
allowed  character  set  shall  be  designated  into  GO  (see  item  i)  above) 
and  invoked  into  GL.  it  is  also  necessary  to  invoke  a  character  set 
into  GR  which  has  been  designated  into  the  Gl,  G2  or  G3  set. 

V)        The  empty  set  shall  be  designated  into  Gl  and  invoked  into  GR  if  no 
other  specific  character  set  is  invoked  into  GR. 

The  code  extension  techniques  allowed  are  illustrated  in  figures  11  and  12. 

The  announcement  and  encoding  of  these  functions  are  to  be  as  specified  in  ISO 
2022. 

The  code  extension  techniques  that  are  used  or  may  be  used  in  a  basic  component 
shall  be  specified  by  the  presentation  attribute  "code  extension  announcers." 
The  default  code  extension  announcers  used  throughout  a  document  may  be 
specified  in  the  document  profile,  using  the  presentation  attribute  "code 
extension  announcers". 


NOTE  -  In  accordance  with  [ISO  8613-6 |CCITT  Recommendation  T.416],  there  is 
no  restriction  concerning  the  number  of  graphic  character  sets  which  may  be 
designated  and/or  invoked  in  the  presentation  attribute  "graphic  character 
sets"  providing  the  restrictions  defined  in  this  subclause  are  applied. 
Hence  designation  to  a  particular  G  set  overrides  a  previous  c'esignation  to 
that  set  and  invocation  to  GL  or  GR  overrides  the  previous  invocation  to 
the  GL  or  GR  respectively.  Thus  the  sequential  order  of  designation  and/or 
invocation  sequences  in  the  attribute  "graphic  character  sets"  is 
significant. 


Figure  11  -  Code  extension  features  (basic  case) 


I 
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6.5.1.5    Line  spacing 

Any  value  of  line  spacing         be  specified.  Values  of  150,  200,  300  and  400  BMUs 
are  basic;  the  use  of  any  other  value  in  a  document  is  non-basic  and  shall  be 
indicated  in  the  document  profile. 

The  line  spacing  may  be  specified  at  the  beginning  of  the  content  associated 
with  a  basic  component  using  the  presentation  attribute  "line  spacing".  The 
value  may  be  changed  anywhere  within  the  content  portion  using  the  control 
functions  SVS  and  SLS. 


6.5.1.6    Character  spacing 

Any  value  of  character  spacing  may  be  specified.  Values  greater  than  or  equal  to 
100  are  basic;  the  use  of  any  other  value  in  a  doctunent  is  non-basic  and  shall 
be  indicated  in  the  document  profile. 

The  character  spacing  may  be  specified  at  the  beginning  of  the  content 
associated  with  a  basic  component  using  the  attribute  "character  spacing".  The 
value  may  be  changed  anywhere  within  a  content  portion  using  the  control 

functions  SHS  or  SCS. 
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NOTES 

1:        A  chzoracter  spacing  of  160  BMUs  is  provided  for  use  with  Korean  Ban- 
gui characters. 

2:        SHS  parameters  of  0,  1,  2,  3  and  4  are  provided.  The  use  of 

parameters  5  and  6  may  be  provided  in  a  future  edition  of  this 
standaurd  for  use  with  Chinese  characters. 


6.5.1.7    Character  path  and  line  progression 

Both  horizontal  and  vertical  writing  directions  may  be  used  within  a  document, 
j  In  the  case  of  horizontal  writing,  the  ch2u:acters  progress  either  from  left  to 

right  or  from  right  to  left  across  the  page  and  the  line  progression  is  from  the 
I  top  of  the  page  to  the  bottom.  In  the  case  of  vertical  writing,  the  cheuracters 
j  progress  from  the  top  of  the  page  to  the  bottom  and  the  line  progression  is  from 
;  the  right  to  the  left.  The  use  of  these  writing  directions  is  restricted  by  the 
j  page  layout  type  used. 

tor  page  layout  A,  only  horizontal  writing  may  be  used  in  the  body,  header  and 
footer  areas.  Thus,  in  this  case  the  cheuracter  path  and  line  progression  is 

I  specified  either  as  0  and  270  degrees  respectively  or  180  and  90  degrees 

;  respectively. 

I  For  page  layout  B,  again  only  horizontal  writing  may  be  used  in  the  body,  header 

j  and  footer  areas.  However,  in  this  case  the  content  in  the  body  area  is 

I  presented  for  viewing  with  the  page  in  landscape  orientation  and  the  content  in 

the  header  and  footer  areas  is  presented  for  viewing  when  the  page  is  in  the 

portrait  orientation. 

I  Thus  for  page  layout  B,  in  the  body  area  the  character  path  and  line  progression 
^  is  specified  either  as  90  and  270  degrees  respectively  or  270  and  90  degrees 

I I  respectively.  In  the  header  and  footer  areas,  the  character  path  and  line 

!|  progression  is  specified  as  in  page  layout  A. 

mI 

jl 

1 1  For  page  layout  c,  only  vertical  writing  nay  be  used  in  the  body  area  and  only 
|!  horizontal  writing  may  be  used  in  the  header  and  footer  areas.  Thus  in  the  body 

area  the  character  path  and  line  progression  are  specified  as  270  and  270 
I  degrees  respectively.  In  the  header  and  footer  areas,  the  cheuracter  path  and 
j  line  progression  is  specified  as  in  page  layout  A. 

|{  For  page  layout  D,  only  vertical  writing  may  be  used  in  the  body,  header  and 

I  footer  areas.  Thus  in  all  these  areas,  the  character  path  and  line  progression 

II  are  specified  as  270  and  270  degrees  respectively. 

I  A  character  path  value  of  0  degrees  and  a  line  progression  value  of  270  degrees 
ii;  are  basic  values.  All  other  values  are  non-basic  and  their  use  in  a  document 
I  shall  be  indicated  in  the  document  profile. 

ll 

I  The  values  of  character  path  and  line  progression  may  be  specified  at  the 
I  beginning  of  the  content  associated  with  a  basic  component  using  the 

presentation  attributes  "character  path"  and  "line  progression"  respectively. 
I  These  values  cannot  be  changed  within  a  content  portion. 
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€.5.1.8    Character  ©riemtation 

The  cheuracter  orientation  may  be  specified  as  0  or  90  degrees  depending  on 
whether  vertical  or  horizontal  writing  is  used  <  see  6.5.1.7). 

When  horizontal  writing  is  used,  characters  nay  only  be  orientated  at  0  degrees. 
When  vertical  writing  is  used;  characters  stay  be  orientated  at  90  degrees. 

A  value  of  0  degrees  is  basic i  a  value  of  90  degrees  is  non-basic  and  its  use  in 

a  document  shall  be  indicated  in  the  document  profile. 

The  value  of  the  character  orientation  is  specified  at  the  beginning  of  the 
content  associated  with  a  basic  component  by  the  presentation  attribute 
"character  orientation".  This  value  cannot  be  changed  within  the  content. 


§.5.1,9    En^hasis  • 

The  following  modes  of  emphasising  graphic  cheuracters  may  be  distinguished: 

-  noEinal  rendition  i 
-''        normal  intensity; 

increased  intensity  (bold); 

-  italiciged; 

-  not  italicized; 
underlined; 

-  doubly  underlined; 
not  underlined; 
erossed-=out; 

-  not  cross©d-out. 

All  the  above  mentioned  modes  of  emphasis  are  basic.  If  no  default  mode  is 
explicitly  specified  in  the  document  profile,  then  the  default  mode  is  normal 
rendition. 

The  mode  of  emphasis  may  be  specified  at  the  beginning  of  the  content  associated 
with  a  basic  component  using  the  presentation  attribute  "graphic  rendition".  The 
mode  may  be  changed  £mywhere  within  the  content  using  the  control  function  SGR. 
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The  mode  of  emphasis  remains  in  effect  within  the  content  associated  with  a 
basic  component  until  changed  into  a  mutually  exclusive  mode  or  by  the 
specification  of  'normal  rendition'.    Mutually  exclusive  modes  are  normal/ 
increased  intensity,  italicized/not  italicized,  underlined/doubly  underlined/not 
underlined  and  crossed  out/not  crossed-out.    one  mode  from  each  mutually 
exclusive  set  may  be  in  operation  at  any  point  in  the  document  content. 

Normal  rendition  cancels  the  effect  of  all  modes  of  emphasis  that  are  currently 
in  operation  and  specifies  that  the  text  shall  be  displayed  in  accordance  with 
the  default  rendition  parameters  set  for  the  presentation  device.  Thus,  for 
example,  if  it  is  required  to  ensiire  that  the  content  is  not  underlined,  then  it 
is  necessary  to  explicitly  specify  that  underlined  is  not  to  be  used. 

6.5.1.10  Tabulation 

Tabulation  stop  positions  may  be  specified  at  any  position  along  the  character 
path.  Each  stop  is  specified  by  means  of  the  following: 

a)  The  tabulation  position  relative  to  the  margin  position  in  the 
direction  opposite  to  the  character  path; 

b)  An  optional  alignment  qualifier  that  specifies  the  type  of  alignment 
to  be  used  at  the  designated  tabulation  position.  The  type  may  be 
specified  as  one  of  the  following: 

-        staort  aligned; 

end  aligned; 

centred; 

aligned  around. 

These  alignment  qualifiers  are  defined  in  [ISO  8613-6 jcciTT  Recommendation 
T416].  If  the  alignment  qualifier  is  not  explicitly  specified,  then  it  is 
assumed  that  start  aligned  is  to  be  used. 

Only  one  set  of  tabulation  stops  can  be  specified  to  be  applicable  to  the 
content  associated  with  a  basic  component.  No  limit  is  placed  on  the  number  of 
tabulation  stops  that  may  be  specified  within  a  given  set. 

The  set  of  tabulation  stop  positions  associated  with  the  content  of  a  basic 
component  sure  specified  using  the  presentation  attribute  "line  layout  tcible". 
Tabulation  stop  positions  are  invoked  within  the  content  using  the  control 
function  STAB. 

The  tabulation  reference  numbers  used  in  the  STAB  controls  and  associated 
presentation  attribute  "line  layout  table"-  shall  be  chosen  so  that,  in  any  given 
line  layout  table  the  reference  numbers  are  unique,  sequential  in  the  direction 
of  the  character  path  and  do  not  include  leading  zeroes. 


51 


F<X>26  Part  1  -  Document  implication  Profile 


July  1992 


6.5.1.11  Indentation 

Indentation  is  the  distance  between  the  first  character  on  a  line  of  content  and 
the  position  of  the  margin  that  is  in  the  direction  opposite  to  the  direction  of 
the  character  path.  Thus  the  value  of  the  indentation  specified  determines  the 
line  home  position  (as  defined  in  [ISO  8613-6|cciTT  Recommendation  T.416]). 

Indentation  acts  as  teo^orary  alteration  in  the  position  of  the  offset  in  the 
direction  opposite  to  the  direction  of  the  character  path.    When  text  is 
formatted,  it  is  intended  to  be  laid  out  between  the  indentation  position  and 
the  margin  position  in  the  direction  of  the  character  path. 

Any  value  of  indentation  may  be  specified  for  basic  logical  components  using  the 
presentation  attribute  "indentation".  The  indentation  value  shall  not  be  changed 
within  a  content  portion. 


6.5.1.12  Alignment 

This  feature  is  concerned  with  how  the  first  and  last  characters  on  each  line  of 
character  content  are  to  be  laid  out  during  the  formatting  process. 

The  following  values  of  alignment  may  be  specified  as  basic: 

start  aligned; 

end  aligned; 

-  centred; 

justified. 

The  semantics  of  these  values  are  as  defined  in  [ISO  8613-6 |CCITT  Recommendation 
T.416]. 

The  presentation  attribute  "alignment"  is  used  to  specify  the  alignment  that  is 
applicable  to  the  content  associated  with  a  basic  component.  The  alignment  value 
cannot  be  changed  within  a  content  portion. 

6.5.1.13  First  line  format 

This  feature  specifies  how  the  first  line  of  the  content  associated  with  a  basic 
component  is  to  be  laid  out  and  provides  for  the  itemisation  of  paragraphs. 

It  allows  the  first  character  in  the  content  to  be  positioned  at  some  point 
along  the  character  path  relative  to  the  indentation  position  (as  specified  in 
6.5.1.11).  This  point  may  be  in  the  direction  of  the  character  path  or  in  the 
direction  opposite  to  the  direction  of  the  character  path  relative  to  the 
indentation  position. 
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In  addition,  this  feature  provides  for  the  specification  of  an  item  identifier 
on  the  first  line.  The  item  identifier  is  a  string  of  characters  that  precedes 
and  is  separated  from  the  remaining  characters  that  form  the  first  line.  The 
control  function  CH  (Carriage  Return)  is  used  as  the  separator. 

The  features  provided  correspond  to  examples  10.1  to  10.5  shown  in  figure  10  of 
[ISO  8613-6|cciTT  Recommendation  T.416], 

First  line  format  is  specified  by  the  presentation  attributes  "first  line 
offset"  and  "itemisation" ,  and  "indentation",    only  those  values  of  the 
attributes  which  combine  to  form  the  examples  shown  in  figure  10  of 
[ISO  8613-6 |cciTT  Recommendation  T.416]  may  be  used. 

€.5.1.14    Widow  and  orphan  sizes 

The  widow  size  specifies  the  minimum  number  of  lines  of  content  that  shall  be 
allocated  to  a  following  frame  or  page  when  the  content  associated  with  a  basic 
logical  component  is  laid  out  such  that  it  flows  over  two  frames  or  pages.  To 
accommodate  this,  it  may  be  necessary  to  move  a  number  of  lines  of  content  from 
one  frame  or  page  to  the  next  frame  or  page. 

The  orphan  size  specifies  the  minimiun  number  of  lines  of  content  that  shall  be 
placed  in  the  current  frame  or  page  when  the  content  associated  with  a  basic 
logical  component  is  split  over  two  frames  or  pages.  If  this  minimum  cannot  be 
accommodated,  then  the  whole  content  shall  be  placed  in  the  next  frame  or  page. 

Any  value  of  widow  or  orphan  size  may  be  specified  using  the  presentation 
attributes  "widow  size"  and  "orphan  size"  respectively. 

Widow  and  orphan  size  may  only  be  specified  for  character  content  placed  in  body 
area  of  pages. 

6.5.1.15  Fonts 

Any  number  of  fonts  may  used  within  a  document.  The  fonts  used  in  a  particular 
document  are  specified  in  the  document  profile  using  the  attribute  "fonts  list". 

Further  information  concerning  the  specification  of  font  references  in  the 
document  profile  is  given  in  Annex  B,2. 

The  fonts  that  may  be  used  within  the  content  associated  with  each  basic 
component  are  specified  by  the  presentation  attribute  "character  fonts".  Up  to 
10  fonts  taken  from  the  list  specified  by  the  attribute  "fonts  list"  may  be 
specified  by  the  attribute  "character  fonts". 

The  font  to  be  used  at  the  staxt  of  the  content  associated  with  a  basic 
•component  is  specified  using  the  attribute  "graphic  rendition".  The  fonts  used 
within  the  content  may  be  changed  using  the  control  function  SGR. 

The  document  profile  may  specify,  using  the  attribute  "character  fonts",  a 
default  set  of  up  to  10  fonts  that  are  applicable  to  the  whole  document. 
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6.5.1. 1€    Reverse  character  strings 

Bi-directional  writing  is  supported  by  this  profile  (see  6.5.1.7).    Hence,  a 
string  of  cheuracters  in  a  content  portion  associated  with  a  basic  component  may 
be  specified  to  be  imaged  in  the  reverse  direction  of  the  immediately  preceding 
character  string.  Such  strings  may  be  specified  by  the  control  function  SRS  as 
defined  in  [ISO  8613-6 |CCITT  Recommendation  T.4161. 

This  control  function  is  provided  for  cases  in  which  the  text  belqngs  to 
different  languages  and  the  character  content  is  written,  for  example,  from  left 
to  right  or  from  right  to  left  within  the  same  line  of  characters,  dependent 
upon  the  language  and/or  character  set  being  used. 

NOTE  -  The  use  of  this  control  function  cannot  be  indicated  in  the  document 
profile.  Thus  it  is  intended  that  implementations  shall  ignore  this  control 
function  when  reverse  character  string  layout  and  presentation  is  not 
supported. 

6.5.1.17  Kerning  offset  . 

A  kerning  offset  value  for  the  content  associated  with  a  basic  component  may  be 
specified  using  the  presentation  attribute  "kerning  offset".  It  is  necessary  to 
specify  such  a  value  when  certain  fonts  &re  invoked  to  ensure  that  no  part  of 
character  images  are  positioned  outside  the  boundary  of  the  available  area. 

6.5.1.18  Proportional  line  spacing. 

The  use  of  proportional  line  spacing  may  be  invoked  for  the  content  associated 
with  a  basic  logical  component  using  the  attribute  "proportional  line  spacing". 
When  this  invocation  occurs,  the  line  spacing  between  each  pair  of  consecutive 
lines  is  determined  in  an  implementation-defined  way  from  the  attributes 
associated  with  the  fonts  used  within  the  two  lines  and  may  vary  from  one  line 
to  the  next.  This  process  is  application  dependent. 

6.5.1.19  Superscripts  and  subscripts 

Superscripts  and  subscripts  may  be  specified  anywhere  within  the  content 
associated  with  a  basic  component  by  using  the  control  functions  FLU  and  PLD. 
The  use  of  these  control  functions  shall  be  in  accordance  with  [ISO  8613-6 |CCITT 
Recommendation  T . 4 16 ] . 

6.5.1.20  Line  breaks 

The  control  functions  BPR  and  NBH  may  be  inserted  in  process2d3le  form  character 
content  to  indicate  where  line  breaks  may  occur  or  may  not  occur  respectively, 
when  the  content  is  laid  out. 
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6.5.1.21    Substitution  of  characters 

The  control  function  SUB  is  provided  to  represent  characters  produced  by  a  local 
system  that  cannot  be  represented  by  a  character  within  a  character  set 
supported  by  this  profile. 

I    6.5.1.22    Initial  point 

I 

The  initial  point  which  is  applicable  to  basic  layout  components  may  be 
specified  by  the  attribute  "initial  offset".  Any  value  may  be  specified. 

I    6.5.1.23    Use  of  control  functions 

1  The  following  is  a  list  of  all  the  control  functions  and  psurameter  values  (where 
I    applicedale)  that  may  be  specified  in  character  content: 


SHS    -  select  character  spacing 

(allowed  parameter  values:  0,  1,  2,  3,  4); 

« 

SCS    -  set  character  spacing 

(allowed  peirameter  values:  any); 

SVS    -  select  line  spacing 

(allowed  parameter  values:  any); 

SLS    -  set  line  spacing 

(allowed  parameter  values:  any); 

SGR    -  set  graphic  rendition 

(allowed  parameter  values:     0,  1,  2,  3,  4,  9-19,  21-24,  29); 

STAB  -  selective  tedsulation 

(allowed  parameter  values:  any); 

SRS    -  start  reverse  string 

(allowed  parameters:  any); 

VPB    -  line  position  backward  (allowed  parameter  values:  any); 

VPR    -  line  position  relative  (allowed  parameter  values:  any); 


PLD 


PLU 


partial  line  up; 


BPH 


break  permitted  here; 


NBH 


no  break  here; 


JFY 


no  justify; 
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SUB 

-  substitute  character; 

SP 

■-  space; 

CR 

-  carriage  return; 

LF 

-  line  feed; 

SOS 

-  start  of  string  ; 

ST 

-  string  terminator 

-  code  extension  control  functions  (see  6.5.1.4). 

The  use  of  all  these  control  functions,  with  the  exception  of  SP,  CR,  LF,  SOS 
and  ST  are  described  in  veorious  sections  in  6.5.1. 

6.5.1.24    Formatting  the  content 

The  attribute  "formatting  indicator"  shall  not  be  specified  within  docvunents 
that  are  conformant  with  this  profile. 

6.5.2    Raster  graphics  content 
6.5.2.1  Introduction 

This  subclause  defines  the  features  that  are  applicable  to  the  raster  graphics 
content  contained  in  a  document.  These  features  aay  apply  to  basic  logical  and 
layout  components  unless  otherwise  indicated. 

The  default  values  for  the  following  features  nay  be  specified  in  the  document 
profile: 

type  of  coding; 

-  compression; 

-  pel  spacing; 

-  spacing  ratio; 
^  clipping; 

-  image  dimensions. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation  or 
coding  attribute  or  control  function  shall  be  indicated  in  the  document  profile. 
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6.5.2.2    Raster  graphics  content  architectures 

Only  the  formatted  proceaszdsle  raster  graphics  content  airchitecture  class  may  be 
used  in  documents  that  conform  to  this  document  application  profile.  This  type 
of  content  may  be  used  in  processable,  formatted  and  formatted  proces sable  form 
documents . 

When  using  raster  graphics  content,  only  one  content  portion  may  be  associated 
with  an  object  or  object  class. 

The  content  information  in  a  content  portion  may  be  absent.  This  is  to  allow  the 
representation  and  interchange  of  documents  in  which  psurts  of  the  content  may  be 
supplied,  for  example,  during  subsequent  editing. 

Also,  the  scalable  or  fixed  dimension  content  layout  process  may  be  used  when 
laying  out  and  imaging  the  content  depending  upon  the  specification  of  the 
presentation  attributes  "pel  spacing"  and  "imaging  dimensions"  as  described  in 
6.5.2.6  and  6.5.2.8.  Both  forms  of  content  layout  processes  may  be  used  in  a 
single  document. 


6.5.2.3  Raister  graphics  encoding  methods 

The  content  may  be  encoded  in  accordance  with  the  encoding  schemes  defined  in 
CCITT  Recommendations  T.4  and  T.6.  In  the  case  of  T.4,  either  the  one- 
dimensional  or  two  dimensional  encoding  scheme  may  be  used.  Also  the  'bit-map 
encoding'  scheme  defined  in  [ISO  8613-7 |cciTT  Recommendation  T.417]  may  be  used. 
All  these  forms  of  encoding  may  be  used  in  a  single  document  and  all  are  basic. 
'Uncompressed'  mode  of  encoding  may  also  be  used  but  as  a  non-basic  feature. 

When  using  the  T.4  or  T.6  encoding  method,  the  relationship  between  the  order  of 
pels  and  the  order  of  bits  in  the  octets  in  the  coded  data  stream  shall  be  such 
that  the  first  pel  in  the  order  of  bits  is  allocated  to  the  least  significant 
bit  of  an  octet.  In  the  case  of  bit-map  encoding,  the  order  of  encoding  shall  be 
that  the  first  pel  is  allocated  to  the  most  significant  bit  of  an  octet. 

In  a  content  portion,  if  content  information  is  specified  then  it  is  required 
that  the  coding  attribute  "number  of  pels  per  line"  is  specified;  the  coding 
attribute  "number  of  lines"  may  also  be  specified.    No  restriction  is  placed  on 
the  values  that  may  be  specified  for  these  coding  attributes.    Thus  this  profile 
places  no  restriction  of  the  size  of  the  pel  arrays  that  may  be  used. 

The  type  of  encoding  method  used  is  specified  by  the  attribute  "type  of  coding". 
The  use  of  this  attribute  is  non-mandatory.  Thus,  if  this  attribute  is  not 
specified  for  a  particular:  content  portion  and  if  the  content  architecture  class 
specified  corresponds  to  the  formatted  proces sible  raster  graphics  content 
architecture  class,  then  the  default  encoding  method  is  assumed  to  be  T.6. 

6.5.2.4  Pel  path  and  line  progression 

The  pel  path  and  line  progression  supported  by  this  profile  are  0  degrees  and 
270  degrees  respectively.  This  profile  does  not  allow  the  specification  of  other 
values . 
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6.5.2.5  Clipping 

A  8ub-region  within  a  pel  eirray  represented  by  a  content  portion  associated  with 
a  basic  component  may  be  defined  using  the  presentation  attribute  "clipping".  No 
restriction  is  placed  on  the  use  of  this  attribute. 


6.5.2.6  Pel  spacing 

The  pel  spacing  is  the  distance  in  BMUs  between  any  two  pels  on  a  line  when  a 
pel  eurray  is  imaged.  Any  value  may  be  explicitly  specified  provided  that  the 
spacing  between  pels  is  not  less  than  1  BMU.  The  pel  spacing  need  not  be  an 
integer  value.  Also,  the  value  'null'  may  be  specified,  indicating  that  the 
scalable  layout  process  is  to  be  used. 

The  specification  of  the  value  'null'  or  spacings  of  16,  12,  8,  6,  5,  4,  3,  2, 
and  1  BMU  between  adjacent  pels  are  basic.  The  specification  of  any  other 
spacing  is  non-basic  and  shall  be  indicated  in  the  document  profile. 

The  pel  spacing  applicable  to  content  associated  with  basic  logical  components 
is  specified  by  the  presentation  attribute  "pel  spacing" . 

NOTES 

1.  The  basic  pel  spacing  values  listed  above  are  equivalent  to 
resolutions  of  75,  100,  150,  200,  240,  300,  400,  600  and  1200  pels 
per  25.4mm  respectively  when  the  document  is  imaged  in  its  specified 
size. 

2.  The  attribute  "pel  spacing"  specifies  two  integers,  the  ratio  of 
which  determines  the  pels  spacing.  No  restriction  is  placed  on  the 
values  of  these  integers. 

6.5.2.7  Spacing  ratio 

The  spacing  ratio  is  the  ratio  between  the  pel  spacing  and  the  line  spacing  when 
a  pel  array  is  imaged.  This  ratio  is  used  to  determine  the  line  spacing  from  the 
pel  spacing  specified. 

No  restrictions  aure  placed  on  the  value  of  this  ratio  providing  that  the 
resultant  line  spacing  is  not  less  than  1  BMU.    Also,  the  line  spacing  need  not 
be  an  integral  number  of  BMUs.  All  values  are  basic. 

The  default  value  may  be  specified  in  the  document  profile.  If  no  default  value 
is  explicitly  specified  then  the  default  value  is  the  ratio  1:1,  that  is,  the 
line  spacing  is  equal  to  the  pel  spacing. 

The  spacing  ratio  applicable  to  the  content  associated  with  a  basic  logical 
component  is  specified  by  the  presentation  attribute  "spacing  ratio". 
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6.5.2.8    Uoage  dimensiona 

The  image  dimensions  are  the  constraints  to  be  applied  to  the  size  of  the  image 
produced  when  laying  out  a  pel  array  represented  by  a  content  portion  associated 
with  a  basic  logical  component. 

These  constraints  are  specified  for  basic  logical  components  by  the  presentation 
attribute  "image  dimensions".  The  value  of  this  attribute  is  only  taken  into 
account  if  the  value  of  the  attribute  "pel  spacing"  is  'null'. 

6.5.3    Geometric  graphics  content 

A  document  may  contain  graphic  images  composed  of  geometric  graphic  content 
encoded  as  C6M  metafiles  in  accordance  with  ISO  8632.  Each  CGM  figure  shauLl 
consist  of  a  single  picture  only.  Each  GCM  figure  may  specify  its  minimum 
dimensions. 

Further  information  concerning  the  specification  of  geqmetric  graphics  content 
information  is  given  in  Annex  B. 

6.6    Miscellaneous  features 

6.6.1  Resource  dociments 

Object  classes  of  the  types  BodyText,  BodyRaster  and  BodyGeometric ,  CommonText, 
CommonRaster,  CommonGeometric  and  GenericBlock  may  refer  to  corresponding 
constituents  in  a  resource  docvunent. 

The  constituents  in  the  resource  document  may  refer  to  content  portions  and  to 
layout  and  presentation  styles  that  are  contained  within  the  resource  document. 
The  constituents  listed  above  are  the  only  ones  that  are  allowed  to  be 
referenced  from  another  document  via  the  resource  attribute:  however  documents 
used  as  a  resource  document  may  contain  any  combination  of  generic  constituents 
which  is  conformant  to  this  document  application  profile. 

6.6.2  External  documents 

In  the  case  of  processable  and  formatted  processable,  the  generic  logical 
structure,  and  the  generic  layout  structure  if  present,  may  be  contained  in  im 
external  document.    Note  that  it  is  not  permitted  to  exchange  one  generic 
structure  in  the  interchanged  docvunent  whilst  referencing  the  other  through  the 
external  document. 

6.6.3  Border 

Border  may  be  specified  for  all  the  frame  types  defined  in  6.3.5  and  6.3.6  using 
I    the  attribute  "border" .  Borders  may  also  be  specified  in  presentation  styles . 
I    All  the  features  of  border  specified  in  [ISO  8613-2 |cciTT  Recommendation  T.412], 
1    nay  be  specified.  The  use  of  border  is  a  non-basic  feature  and  shall  be 
1    indicated  in  the  document  profile.  Border  shall  not  be  specified  for  the 
I    constituents  GenericBlock  and  specif icBlock. 
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6.6.4  Application  cammMita 

Specification  of  the  attribute  "application  comments"  is  mandatory  for  all 
object  classes  contained  in  a  document  that  conforms  to  this  profile. 
Specification  of  this  attribute  is  mandatory  for  all  objects  that  do  not  refer 
to  an  object  class.    Specification  of  this  attribute  is  optional  for  all  objects 
that  refer  to  object  classes. 

This  attribute  is  structured  so  that  it  contains  two  fields.  The  first  field  is 
mandatory  when  the  attribute  is  specified  and  contains  a  niimeric  string  which 
uniquely  identifies  the  constituent  constraint  applicable  to  the  constituent  for 
which  the  attribute  is  specified.  This  facilitates  the  processing  of  documents. 
A  list  of  these  identifiers  is  given  in  table  2. 

NOTES  I 

1:    The  values  of  the  constituent  constraint  numeric  identifiers  are  not 
unique  between  the  logical  and  layout  structures  and  therefore  in  order  to 
identify  the  constituent  constraint  applicable  to  a  constituent  it  is 
necessary  to  know  the  structure  of  which  the  constituent  is  a  part. 

*        2:    For  constituent  constraints  that  correspond  to  each  other  between  the 
hier2u:c hie ally  related  profiles  to  which  this  profile  belongs,  the  same 
constituent  constraint  numeric  identifier  is  specified. 

The  second  field  is  optional  and  nay  contain  any  information  that  is  relevant  to 
the  application  or  user.  The  format  of  the  second  field  is  not  defined  in  this 
profile  and  the  interpretation  of  this  field  depends  upon  a  private  agreement 
between  the  originator  and  recipient  of  the  document. 

The  encoding  of  the  attribute  "application  comments"  is  defined  in  8.1.3.  and 
8.2.3. 

6.6.5  Alternative  representation 

The  content  information  in  a  content  portion  ns^  be  replaced  by  a  string  of 
characters  specified  in  the  attribute  "alternative  representation" .  This 
attribute  may  be  specified  in  content  portions  that  contain  character,  raster 
graphics  or  geometric  graphics  content. 

The  specification  and  use  of  this  attribute  is  optional.  The  string  of 
characters  specified  shall  belong  to  the  character  repertoires  indicated  in  the 
document  profile  attribute  "alternative  representation  character  sets"  (see 
6.7.4.3).  If  the  latter  attribute  is  not  explicitly  specified  in  the  document 
profile,  then  the  default  defined  in  ISO  8613  is  assumed.    The  control  functions 
CR,  LF  and  SP  max  also  be  used  within  the  character  string  but  no  other  control 
function  is  allowed;  hence  graphic  character  sets  cannot  be  changed  within  the 
alternative  representation. 

6.6.6  Page  Hmobering 

As  described  in  6.2.4.3,  the  constituent  constraint  PageNumber  contains  a 
content  generator  which  nay  refer  to  a  page  number.  This  content  generator  is 
evaluated  when  the  docvunent  is  laid  out  and  this  mechanism  provides  a  means  of 
reproducing  the  appropriate  number  of  each  page  of  a  doeiiment. 
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Th©  content  f®0®rator  has  th®  followiag  feraats 

<8trinf-'lit©ralxnuiffi<^3^rx@tri»g"lit©r®l> 

The  format  ©f  this  e©at@Bt  generator  is  defined  in  th©  macro  P6NUMBER  (m®® 
note) « 

The  <Btring-literal>  fields  are  optional  and  are  pre-defined  character  strings. 
The  basic  character  repertoire  used  to  specify  these  strings  is  the  prisiary 
character  repertoire  of  ISO  8859-1.  Any  other  character  repertoire,  and 
subrepertoire  if  appropriate,  may  be  used  provided  that  it  is  designated  and 
invoked  by  the  appropriate  code  designation  and  innovation  sequences,  and 
indicated  in  the  document  profile  as  a  non-basic  value.  SP  and  no  other  control 
functions  may  be  used  in  th@s@  strings  <> 

The  field  <num-expr>  is  a  reference  to  a  binding  PGnum  which  specifies  the 
number  of  the  page  concerned.  This  binding  is  initialised  at  the  document  layout 
root  or  page  set  level  (see  the  macro  INITIALZSEPGNUM  in  7.4.1)  and 
automatically  incremented  on  each  successive  page  (see  macro  pagenumber  in 
7.4.1).    By  placing  initialisation  on  the  layout  root,  rather  than  on  the 
pageset  class (es),  the  pagenumbering  maY  be  defined  to  be  continued  from  one 
pageset  to  the  next. 

The  content  associated  with  logical  object  classes  of  the  type  PageNumber  is 
laid  out  in  a  frame  of  one  of  the  following  types:  BasicHeader,  BasicFooter, 
SourcedContentVariedale,  SourcedContentFixed  (see  6.3.6)  using  the  logical  source 
mechauiism.  Thus  when  the  appropriate  frame  is  being  laid  out,  the  field  <num- 
expr>  in  the  content  generator  contained  in  a  logical  object  class  of  the  type 
PageNumber  is  evaluated  and  this  determines  the  value  of  the  binding  PGnum  that 
is  associated  with  the  current  page  being  laid  out. 

The  number  associated  with  the  binding  PGnum  is  applied  to  &  string  function 
during  its  evaluation  in  order  to  convert  the  number  into  a  character  string. 
This  enables  the  number  to  be  represented  in  the  form  of  an  Arabic  numeric 
string,  an  upper  or  lower  case  Roman  numeric  string  or  an  upper  or  lower  case 

alphabetic  string. 

Each  page  class  may  refer  t©  a  different  instance  of  logical  object  classes  of 
the  type  PageNumber  and  this  allows  different  page  numbering  formats  to  be  used 
for  different  parts  of  the  document. 

An  example  of  page  numbering  is  "Page  X"  which  consists  of  two  concatenated 
character  strings.    The  first  is  the  literal  character  string  'Page'  and  this  is 

concatenated  to  a  string  function  denoted  by  ^l*'^    Wb©n  ^K'  is  evaluated  in  a 
particular  instance  it  may,  for  example,  return  the  character  string  'iv,  the 
Roman  numeral  (lower  case)  for  the  niunber  M'. 

NOTE  -  Unless  otherwise  stated,  the  macros  referred  to  in  this  clause  are 
defined  in  7.3.1. 


6 .  S  e  1    s@<^@nt  numbering 

As  described  in  section  6.2.3.4,  the  constituent  Number  contains  a  content 
generator  which  when  evaluated  during  the  layout  process  produces  an  identifier 
which  serves  to  identify  the  Numbered  Segment  to  which  the  constituent  Number 
belongs . 
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The  format  of  this  identifier  is  as  follows: 

j  <pre-strxntun-strxsuf-str> 

This  format  is  defined  in  the  macro  SEGMENTNUMBER  (see  note). 

The  fields  <pre-str>  and  <suf-str>  are  optional  prefix  and  suffix  chauracter 
I  strings  respectively  which  may  be  of  any  length.  The  basic  cheuracter  repertoire 
used  to  specify  these  strings  is  the  primary  character  repertoire  of  ISO  8859-1. 
Any  other  character  repertoire,  and  subrepertoire  if  appropriate,  may  be  used 
provided  that  it  is  designated  and  invoked  by  the  appropriate  designation  and 
innovation  sequences  and  indicated  in  the  document  profile  as  a  non-basic  value. 
I  Ho  other  control  functions  may  be  used  in  these  strings. 

The  field  <num-str>  is  the  segment  identifier  which  consists  of  a  single  number 

or  a  sequence  of  two  or  more  numbers,  each  of  which  is  separated  by  a 

' sepeorator ' .  The  separator  is  a  character  string  and  may,  for  example,  consist 

'  of  a  full  stop  or  space.  An  example  of  a  segment  identifier  is  '6.3.4.2.1'.  Thus 

I  segment  identifiers  have  the  general  form: 

<niunber>[<separatorxnumber>] . . . 

I  where  [..]...  indicates  optional  repetition. 

In  a  document,  the  prefix  and  suffix  character  strings  are  string  literals  or 
j  carried  by  the  bindings  'prefix  -<n>'  and  'suffix  -<n>  respectively.  The 
separator  character  strings  are  carried  by  bindings  of  the  form  <S9parator-<n>' 
and  the  segment  identifier  <num-str>  is  carried  by  the  binding  'numberstring- 
<n>' . 

In  all  these  bindings  '<n>'  is  a  sequence  of  one  or  more  digits  which  indicate 
!  the  depth  of  numbering,  such  that  n=l  indicates  the  number  (prefix,  suffix, 

numberstring  etc)  for  the  numbered  segments  immediately  subordinate  to  a 
I  Passage,  n-2  indicates  the  number  (prefix,  suffix,  separator  etc)  for  the 
numbered  segments  immediately  svibordinate  to  the  first  level  of  numbered 
segments,  and  so  on.    The  level  number  shall  be  indicated  using  the  smallest 
possible  number  of  characters,  that  is^  there  shall  be  no  leading  zeroes. 

These  bindings  may  be  initialised  at  the  document  logical  root,  passage  or  at 
any  numbered  segment  level  to  start  the  numbering  scheme  sequence  at  a 

!  subordinate  level  of  numbered  segment.  They  may  also  be  re-specified  at  any 
level  within  the  numbering  scheme.  The  initialisation  of  bindings  is  specified 

j  by  the  macro  INITIALISEANY. 

I  The  placement  of  bindings  initialisations  for  numbering  schemes  is  significant. 
Initial  values  for  numbers-n  bindings  shall  be  placed  either  at  the  Passage 
level,  or  on  the  Numberedsegment  class  which  is  superior  to  that  in  which  the 
,  binding  will  be  referenced,     similarly,  prefix  and  suffixes  and  separators  shall 
I  be  initialised  either  at  the  Passage  or  at,  the  immediately  superior 

Numberedsegment  level  to  their  use.    In  particular  note  the  "prefix"  and 
I   "suffix"  are  not  inherited  by  lower  levels  in  hierachy  (since  they  belong  to  the 
I  content  generator  SEGMENTNUMBERS  rather  than  the  binding  Numberstrings-n) .  Thus 
I  to  have  concatenation  to  say  "(l).a",  lower  level  shall  have  a  prefix  of  "("  and 
i  separator  of ") . 


63 


FOD26  Part  1  -  Document  Application  Profile 


July  1992 


In  order  to  evaluate  the  value  of  ' number string-<n>'  for  each  numbered  segment, 
a  number  is  assigned  to  each  numbered  segment  at  a  given  level.  If  the  numbered 
segments  etre  all  of  the  same  class  then  this  niunber  nay  be  determined  by  the 
ORDINAL  niuneric  function.  If  they  are  of  different  classes,  then  the  number  is 
carried  by  a  binding  of  the  form  'number-<n>' . 

A  different  binding  of  the  type  'number-<n>'  is  used  for  each  numbered  segment 
level  and  is  initialised  at  a  higher  level  constituent  than  the  one  in  which  it 
is  used.  The  number  associated  with  each  numbered  segment  level  is  automatically 
incremented  for  each  successive  numbered  segment  (see  the  macro  USENUMBERS ) . 

The  binding  'numberstring-<n>'  that  is  applicable  to  a  given  level  of  numbered 
segment  is  now  constructed  as  follows: 

<numberstring-xxseparator-yxnumber-z> 

Hence,  the  segment  identifier  consists  of  a  concatenation  of  up  to  three  fields. 
The  field  <numberstring-x>  is  a  reference  to  the  segment  identifier  applicable 
to  the  immediately  superior  level  of  numbered  segment  (if  any).  This  identifier 
is  in  the  form  of  a  character  string.  The  field  <separ£^tor-y>  is  a  reference  to 
a  separator  defined  at  some  higher  level  in  the  document  structure. 

The  field  <number-z>  is  the  number  applicable  to  the  given  ntimbered  segment 
whose  identifier  is  being  constructed.  As  indicated  above,  this  number  may  be 
determined  from  an  ORDINAL  expression  or  by  reference  to  a  binding  of  the  form 
'number-<n>'  which  is  specified  for  the  same  numbered  segment  whose  identifier 
is  being  constructed.  In  either  case,  a  string  function  is  applied  to  the  number 
to  convert  it  into  a  character  string.  This  string  function  allows  the  number  to 
be  represented  in  one  of  the  following  forms:  Arahic  number  string,  upper  or 
lower  case  Roman  numeral  string,  or  upper  or  lower  case  alphabetic  characters. 
This  construction  is  defined  in  the  macro  USENUMBERSTRINGS . 

The  constructed  binding  of  the  form  ' number string-<n>'  is  then  available  for 
constructing  the  identifiers  at  lower  levels  of  nvimbered  segments.  This  binding 
is  also  referred  to  in  a  content  generator  carried  by  the  constituent  Number, 
which  causes  the  identifier  (with  optional  prefix  and  suffix  strings)  to  be 
generated  and  reproduced  when  the  document  is  laid  out. 

NOTE  -  The  macros  referred  to  in  this  clause  are  defined  in  7.3.1. 

6.6.8    Footnote  niunbering 

A  footnote  number  is  a  character  string  that  identifies  a  given  footnote.  The 
format  of  this  string  is  as  follows: 

<8tring-literalxnum-strxstring-literal> 

This  format  is  defined  in  the  macro  FNOTENUMBER. 

The  <string-literal>  fields  are  optional' and  are  pre-defined  prefix  or  suffix 
character  strings.  The  basic  character  repertoire  used  to  specify  these  strings 
is  the  primary  cheuracter  repertoire  of  ISO  8859-1.  Any  other  chzoracter 
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repertoire ;  and  subrepertoire  if  appropriate,  may  be  used  provided  that  it  ia 
designated  and  invoked  by  the  appropriate  designation  and  innovation  sequences, 
and  indicated  in  the  document  profile  as  a  non-basic  value.  No  other  control 
functions  nay  be  used  in  these  strings. 

The  field  <niun-8tr>  is  an  automatically  generated  numeral  or  a  user  supplied 
character  string  that  generally  serves  to  identify  a  particular  footnote. 
Numerals  may  be  represented  in  the  form  of  Arabic  numerals,  upper  or  lower  case 
Roman  numerals  or  upper  or  lower  case  Alphedsetic  characters.  Automatically 
generated  footnote  niimbers  are  incremented  sequentially  from  an  initial  value 
which  may  be  set  to  any  positive  value  at  the  beginning  of  the  document  and 
reset  at  any  passage. 

A  single  binding  'fnotentuober'  is  provide  to  represent  footnote  numbers.  This 
may  be  initialised  to  any  non~negative  number  at  the  logical  root  or  on  any 
Passage  (see  specification  of  the  macro  INITIALISEFNOTE) . 

The  footnote  n\unb@r  is  incremented  using  a  binding  expression  at  each  footnote 
object  (see  the  macro  INCFNOTENUMBER) .  This  is  then  made  into  a  character  string 
using  a  string  function.  This  value  is  assigned  to  the  'binding  'fnoteatring' 
(see  the  macro  FNOTENUNBERSTRING) . 

Alternatively,  a  character  string  literal  may  be  assigned  to  the  binding 
'fnotestring' ;  this  provides  the  user  with  the  ability  to  supply  particular 
footnote  labels  for  individual  footnotes  ( see  the  macro  FNOTESTRINGLITERAL ) . 

The  constituents  FootnoteReference  and  FootnoteNumber  contain  content  generators 
whose  format  is  defined  by  the  macro  FNOTENUHBER.  As  indicated  above,  this 
format  consists  of  a  field  represented  by  <num-str>  which  has  optional  prefix 
and  suffix  string  literals.  The  field  <num-str>  consists  of  a  reference  to  a 
binding  'fnotestring'  which  specifies  the  number  of  the  footnote  in  the  form  of 
a  character  string. 

6.6.9  User  readable  comments 

Information  which  is  to  be  interpreted  as  comments  relevamt  to  constituents  and 
associated  content  portions  may  be  specified  using  the  attribute  "user  readedsle 
comments".  This  information  is  intended  for  presentation  to  humans. 

The  information  consists  of  a  string  of  characters  which  shall  belong  to  one  of 
the  character  repertoires  indicated  in  the  document  profile  attribute  "conments 
character  sets"  (see  6.7.4.2).  If  the  latter  attribute  is  not  explicitly 
specified,  then  the  default  defined  in  ISO  8613  is  assumed.    The  control 
functions  CR,  LF,  SP  and  code  extension  control  functions  may  also  be  used 
within  the  character  string  but  no  other  control  functions  are  allowed. 

6.6.10  User  visible  name 

Information  which  nay  be  used  to  identify  constituents  within  a  document  may  be 
specified  using  the  attribute  "user  visible  name".  This  information  is  intended 
for  presentation  to  humans,  for  example to  assist  in  the  editing  of  documents. 
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The  information  consists  of  a  string  of  characters  which  shall  belong  to  one  of 
the  chauracter  repertoires  indicated  in  the  document  profile  attribute  "comments 
character  sets'*  (see  6. .7.4.2).  If  the  latter  attribute  is  not  explicitly 
specified,  then  the  default  defined  in  ISO  8613  is  assumed.    The  control 
functions  CR,  LF,  SP  and  code  extension  control  functions  nay  also  be  used 
within  the  character  string  but  no  other  control  functions  are  allowed. 


6.7    Document  management  features 

Information  relating  to  the  document  as  a  whole  is  specified  in  the  document 
profile  which  is  represented  by  the  constituent  DocumentProf ile .  This 
constituent  shall  be  specified  in  every  document. 

The  information  in  the  document  profile  is  classified  into  the  following 


categories 

• 

i) 

document  constituent  information; 

ii) 

document  identification  information; 

iii) 

document  default  information; 

iv) 

non-basic  characteristics  information; 

V) 

document  meuiagement  information. 

The  information  in  the  docvunent  profile  may  be  of  interest  to  the  user  or  may  be 
used  for  machine  processing  of  the  document. 

6.7.1    Document  constituent  information  i 

This  information  specifies  which  constituents  are  used  to  represent  the 
document,  including  constituents  that  are  external  to  the  interchanged  document,  j 
This  information  is  divided  into  three  categories. 

6.7.1.1    Presence  of  document  constituents  i 

n 

This  information  indicates  which  constituents  are  included  in  the  document.  That 
is,  this  information  indicates  whether  or  not  the  document  contains  a  generic 
logical  structure,  a  specific  logical  stmicture,  a  generic  layout  structure,  a 
specific  layout  structure,  layout  styles  and  presentation  styles  (see  note).  It  ' 
is  mandatory  to  specify  this  information  in  the  document  profile. 

NOTE  -  If  the  generic  logical  or  layout  structure  is  external  to  the 
document  ( see  6.7.1.3),  then  it  is  still  necessary  to  indicate  that  these 
structures  are  present  and  form  part  of  the  docximent. 
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6.7.1.2  Resource  document  information 

This  information  consists  of  a  reference  to  a  resource  document  ( see  6.6.1). 
This  is  specified  by  the  attribute  "resource  document",  if  constituents  in  the 
document  contain  references  to  object  classes  in  a  resource  document,  then  it  is 
nandatory  to  specify  this  information  in  the  document  profile. 

6.7.1.3  External  document  information 

This  information  consists  of  a  reference  to  an  external  document  which  may 
consist  of  a  generic  logical  structure,  or  both  generic  layout  and  generic 
logical  structures  (see  6.6.2).  If  such  a  reference  is  required,  then  it  is 
specified  by  the  attribute  "external  document  class"  in  the  document  profile. 

6.7.2    Documen't  identification  information 

This  information  relates  to  the  identification  of  the  document.  This  information 
is  divided  into  six  categories.  , 


6.7.2.1  Document  application  profile  information 

This  information  indicates  the  document  application  profile  to  which  the 
document  belongs.  It  is  mandatory  to  specify  this  information  using  the 
attribute  "dociiment  application  profile". 

6.7.2.2  Document  architecture  class  information 

This  information  indicates  the  document  architecture  class  to  which  the  docximent 
belongs  (see  6.1).  It  is  mandatory  to  specify  this  information  using  the 
attribute  "document  architecture  class". 


6.7.2.3  Content  architecture  classes  information 

This  information  indicates  the  content  architecture  classes  used  in  the  dociiment 
(see  6.5.1.2,  6.5.2.2  and  6.5.3).  It  is  mandatory  to  specify  this  information 
using  the  attribute  "content  architecture  classes". 

6.7.2.4  Interchange  format  class  information 

This  information  indicates  the  interchange  format  class  used  to  represent  the 
document  (see  clause  8).  It  is  mandatory  to  specify  this  information  using  the 
attribute  "interchange  format  class". 
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6.7.2.5    ODA  version  infoniia1:ion 

This  information  indicates  the  ISO  standard  or  CCITT  Recommendation  to  which  the 
document  conforms.  It  also  specifies  a  calendar  date,  which  indicates  that  the 
document  conforms  to  the  version  of  the  ISO  standard  or  CCITT  Recommendation  and 
any  addenda  that  are  current  on  that  date.  It  is  mandatory  to  specify  this 
information  using  the  attribute  "ODA  version". 


6.7.2.6    Document  reference 

This  information  serves  to  identify  the  document.  Typically  this  information  is 
allocated  to  the  document  by  the  creator  of  the  document.  The  identifier  may 
consist  of  an  ASN.l  object  identifier  or  a  string  of  characters.  It  is  mandatory 
to  specify  this  information  using  the  attribute  "document  reference" . 


6.7.3  Document  default  information 

This  information  specifies  various  default  values  for  attributes  used  in  the 
document.  The  default  values  that  are  allowed  are  specified  in  clause  6.  The 
specification  of  this  information  is  only  required  when  it  is  required  to 
specify  a  default  value  which  is  other  than  the  standard  default  value  specified 
in  [ISO  8613|t.410  series  of  CCITT  Recommendations]. 

Default  values  for  the  following  groups  of  attributes  may  be  specified: 

-  document  architecture  attributes; 
character  content  attributes; 

-  raster  graphics  attributes; 

-  geometric  graphics  attributes. 

6.7.4  Mon-basic  characteristics  information 

This  information  specifies  the  non-basic  attribute  values  specified  in  the 
document.  It  is  mandatory  to  specify  a  non-basic  attribute  value  in  the  document 
profile  when  such  a  value  is  used  in  the  document. 

The  following  types  of  non-basic  attribute  values  may  be  specified: 

profile  character  sets; 

comments  character  sets; 

alternative  representation  cheCracter  sets; 

-  page  dimensions; 
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mediiim- types ; 

-  layout  paths; 

-  borders; 

character  presentation  features; 

raster  graphics  presentation  features; 

raster  graphics  coding  attributes. 

Further  infonnation  concerning  document  profile,  comments  and  alternative 
representation  character  sets  is  given  below. 


6.7.4.1    Profile  character  seta 

Some  document  profile  attributes  have  values  consisting  of  character  strings, 
for  example,  the  document  management  attributes.  The  character  sets  used  in 
^hese  character  strings  are  specified  by  the  document  profile  attribute  "profile 
character  sets". 

Shis  attribute  "profile  cheiracter  sets"  specifies  a  code  extension  announcer  and 
designations  of  chaLcacter  sets,  which  are  subject  to  the  following  restrictions: 


i)  The  code  extension  announcer  shall  be  04/03  when  specified.  This 
code  extension  announcer  specifies  the  use  of  60  and  61  sets  in  an  8- 
bit  environment  and  also  the  invocation  of  60  and  61  sets  into  6L  and 
GR  respectively.    Thus,  in  each  attribute  to  which  this  attribute 
applies,  invocation  shift  functions  are  not  necesscury,  because  60  and 
61  sets  are  implicitly  invoked  by  this  code  extension  announcer. 

ii)  60  set:  only  ISO-IR6  (the  IRV  of  ISO  646  revised  1991),  IS0-IR2  (the 
primary  set  of  ISO  6937-2),  or  any  other  version  of  ISO  646  may  be 
designated  for  this  set;  these  graphic  character  sets  are  implicitly 
invoked  in  6L. 

iii)  61:  no  restrictions  are  placed  on  the  graphic  chauracter  sets  that  may 
be  designated  for  this  set;  these  graphic  character  sets  are 
implicitly  invoked  in  6R. 

iv)  The  empty  set  ahall  be  designated  into  61  and  invoked  into  6R  if  no 
other  specific  set  is  invoked  in  6R. 

If  the  attribute  "profile  character  sets"  is  not  specified,  then  the  default 
defined  in  ISO  8613  is  assumed. 


6.7.4.2    Conmeats  character  sets 

The  character  sets  assumed  to  have  been  designated  and  optionally  invoked  at  the 
beginning  of  the  character  strings  specified  by  the  attributes  "user  readable 
comments"  (see  6.6.9)  and  "user  visible  name"  (see  6.6.10)  are  specified  using 
the  document  profile  attribute  "comments  character  sets". 
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It  alao  specifies  the  code  esctension  techniques  and  the  graphic  character  sets  ' 
which  nay  be  used  in  the  attributes  "user  readable  comments"  and  "user  visible 
name". 

Z£  this  attribute  is  specified,  the  code  extension  techniques  which  may  be  used 
in  the  attributes  "user  readable  comments"  and  "user  visible  name"  shall  be 
announced  by  appropriate  code  extension  announcers.    The  use  of  GO  set  and  GL 
shall  always  be  announced,  other  code  extension  announcers  are  to  be  specified 
according  to  the  requirements  of  a  particultu:  docximent.  | 

Two  kinds  of  code  extension  techniques  are  permitted  for  this  attribute,    one  is  ! 
to  use  GL  and  GR  without  shift  functions,  and  the  other  is  to  use  various 
character  sets  by  shift  functions.    The  former  is  rather  restricted  but  no  shift 
functions  are  necessary  in  the  "user  readable  comments"  and  "user  visible  name". 

The  same  restriction  as  in  6.7.4.1  is  applied  in  this  case.    The  latter  permits 
various  usages  of  character  sets  but  invokations  shall  be  specified  by  shift 
functions  in  the  "user  readable  comment"  and  "user  visible  name". 

The  same  restriction  as  in  6.5.4  is  applied  in  this  case.  | 

All  the  graphic  character  sets  which  nay  be  used  in  the  attribute  "user  readable 
comments"  and  "user  visible  name"  shall  be  designated  in  the  "comments  cheuracter  i 
sets". 

There  are  no  restrictions  concerning  the  number  of  graphic  character  sets  which 
are  designated  and/or  invoked  in  the  "conments  character  sets";  hence 
designation  to  the  same  G  set  overrides  the  previous  G  set.  ^ 

If  the  attribute  "comments  character  sets"  is  not  specified,  then  the  default 
defined  in  ISO  8613  is  assumed. 


6.7.4.3    Alternative  representation  character  sets 

This  attribute  specifies  the  graphic  character  sets  designated  and  invoked  at 
the  beginning  of  the  attribute  "alternative  representation"  other  than  the 
standard  default  graphic  character  sets. 

The  restriction  on  profile  character  sets  described  in  6.7.4.1  is  also  applied. 
If  this  attribute  is  not  explicitly  specified  in  the  docximent  profile,  the 
default  defined  in  ISO  8613  is  assumed. 


6.7.5    Fonts  list. 

This  information  specifies  all  the  fonts  (if  any)  used  in  the  document.  It  is 
specified  using  the  attribute  "fonts  list".     (See  ANNEX  B.2). 
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6.7.6    Docuaent  BBanagement  attributes 

Document  management  attributes  contain  information  about  the  content  of  the 
document  and  its  purpose.  Information  relating  to  the  following  w^y  be 
specified: 

document  description  ( see  note ) ; 

dates  and  times; 

'  -  ■  originators; 

-  other  user  information; 
external  references; 
local  file  references; 

content  attributes;  . 

-  security  information. 

The  attributes  that  nay  be  used  to  specify  this  information  are  defined  in  [ISO 
8613-4|CCITT  Recommendation  T.414]. 

I  The  string  of  ch2u:acters  used  in  the  document  management  attributes  shall  belong 
to  the  cheuracter  sets  indicated  in  the  document  profile  attribute  "profile 
character  sets"  (see  6.7.4.1).  If  the  latter  attribute  is  not  explicitly 
specified  in  the  document  profile,  then  the  default  character  set  is  the  minimum 
subrepertoire  of  ISO  6937-2. 

The  control  functions  SP,  CR  and  LF  may  also  be  used  within  the  character 
I  strings  but  no  other  control  functions  are  allowed.  Hence  the  graphic  character 
»  set  cannot  be  changed  in  the  document  management  attributes. 

NOTE  -  The  document  description  includes  the  specification  of  the  document 
reference  (see  6.7.2.6). 
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7    Specifieatioa  of  constit.'nant  constraln-ts 

This  clause  specifies  the  definition  of  the  constituent  constraints  which  may  be 
represented  by  data  stremns  conforming  to  this  profile. 


7.1  Introduction 

The  structure  diagrams  illustrating  the  relationships  between  the  constituents 
in  the  logical  structures  are  shown  in  7.1.1.    The  macros  indicated  on  these 
diagrams  are  defined  in  7«3.1.  These  macros  define  the  permissible  values  for 
the  attribute  "generator  for  subordinates"  that  are  applicable  to  the 
constituents  and,  in  effect,  define  the  allowed  structures  that  are  supported  by 
this  profile. 

The  structure  diagrams  illustrating  the  layout  structures  are  shown  in  7.1.2. 
The  macros  indicated  in  these  diagrams  are  defined  in  7»4.1. 
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Figure  13:  The  'body'  part  of  the  generic  logical  structure 
-  the  passage  and  numbered  segment  levels 


Figure  14:  The  'body'  part  of  the  generic  logical 
structure  -  the  paragraph  level 


73 


FOD26  Part  1  -  Document  Application  Profile  Jtily  1992 


Fifure  15:  The  'cooanoQ'  part  of  the  generic  logical  structure 
7.1.2  Diagrams  of  relationships  of  layout  constituents 


Figure  16:  The  layout  structure  -  document  root  and  page  sets 
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Figure  17  z  The  layout  structure  -  the  page  structure 


Figure  18;  The  layout  stmcture  ■=  the  header  and    footer  frame  structure 
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7.1.3  Notation 

This  clause  is  written  in  accordance  with  the  Document  Application  Profile 
Proforma  and  Notation  (DAPPN)  of  ISO  8613-1,  Annex  F.    The  following 
clarifications  and  minor  extensions  apply: 

1)  [Clarification] 

The  value  range  definition  for  the  attributes  "subordinates'*  and  "imaging 
order"  specify  the  set  of  object  instances  that  may  occur.    The  ordering 
and  number  (which  may  be  zero)  of  object  instances  for  the  attribute 
"subordinates"  ehall  be  in  accordance  with  the  value  of  the  attribute 
"generator  for  svibordinates"  in  the  respective  object  class. 

2)  [Clarification] 

The  value  "ANY_STRING"  may  include  code  extension  control  functions  as  well 
as  graphic  characters. 

3)  [Extension]  . 

In  order  to  write  the  specification  of  the  usage  of  character  sets  and  code 
extension  control  functions  precisely,  the  following  extensions  are 
applied : 

a)  Following  symbols  are  introduced  to  denote  shift  functions: 


symbol 

Shift  function 

Coded  representation 

LSO 

Locking  shift  zero 

00/15 

LSIR 

Locking  shift  one  right 

ESC  07/14 

LS2R 

Locking  shift  two  right 

ESC  07/13 

LS3R 

Locking  shift  three  right 

ESC  07/12 

SS2 

single  shift  two 

08/14 

SS3 

single  shift  three 

08/15 

b)  <escape-8eguence>  is  extended  to  include  shift  functions: 

<escape-seguence>:  :«'ESC'<octet>. . .  [<invocation-control-function>] ; 
<invocation-control-function>:  :»'LSO'  |  'LSlR'  |  'LS2R'  |  'LS3R'  |  'SS2'  |  'SS3'; 

c)  Data  type  specification  for  #ESC  in  content  information  is  extended  as: 

<escape-seguence>. . . 
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T.2  Document  profile  constituent  constramits 
7.2.1    Macro  definitions 


DEFINE  (FDA,  ' 
DEFINE  (PDA, 
DEFINE  (FPDA, 
DEFINE  (DAC, 


•ASN.1{2  8  2  6  0}"  —  formatted  character  content  — ) 
*ASN.1{2  8  2  6  1}"  —  procesaable  character  content  — ) 
'ASN.1{2  8  2  6  2}"  —  formatted  procesaable  character  content  — ) 
*ASN.1{2  8  2  7  2}**  —  formatted  processable  raster 

graphics  content  — ) 
■°  formatted  processable  geometric 

graphics  content  — ) 

{ 'formatted'}") 

{ 'processcdsle'}**) 

" { ' f ormatted-processable ' } " ) 

DocumentProf ile  (Document-architecture-class)") 


DEFINE  (FC, 
DEFINE  (PC, 
DEFINE  (FPC, 
DEFINE  (FPR, 


DEFINE(FPG,   "ASN.1{2  8  2  8  0}' 


DEFINE (NominalPageSizes,  " 

REQ  #horizontal-dimension  {7015}, 

REQ  #vertical -dimension  {9920} 
|req  #horizontal-dimension  {9920}, 

REQ  Ivertical-dimension  {7015} 
|req  #horizontal-dimension  {9920}, 

REQ  fvertical-dimension  {14030} 
I REQ  #horizontal-dimension  {14030}, 

REQ  #vertical -dimension  {9920} 
I REQ  #horizontal -dimension  {14030}, 

REQ  #vertical -dimension  {19840} 
I REQ  #horizontal-dimension  {19840}, 

REQ  #vertical-dimension  {14030} 
|req  thorizontal -dimension  {12141}, 

REQ  ivertical-dimension  {17196} 
I REQ  Ihorizontal-dimension  {17196}, 

REQ  #vertical -dimension  {12141} 
I REQ  #horizontal-dimension  {8598}, 

REQ  fvertical-dimension  {12141} 
I REQ  fhorizontal-dimension  {12141} 

REQ  fvertical-dimension  {8598} 
jREQ  #horizontal-dimension  {10200} 

REQ  fvertical-dimension  {16800} 
I REQ  fhorizontal-dimension  {16800} 

REQ  fvertical-dimension  {10200} 
|req  fhorizontal-dimension  {10200} 

REQ  fvertical-dimension  {13200} 
|req  fhorizontal-dimension  {13200} 

REQ  fvertical-dimension  {10200} 
jREQ  fhorizontal-dimension  {13200} 

REQ  fvertical-dimension  {20400} 
|req  fhorizontal-dimension  {20400} 

REQ  fvertical-dimension  {13200} 
") 


— ■  ISO  A5  portrait — 


ISO 

A5 

landscape- 

ISO 

A4 

portrait — ■ 

ISO 

A4 

landscape- 

ISO 

portrait— 

ISO 

A3 

landscape- 

JIS 

34 

( Japanese 

legal) 

portrait — 

JIS 

B4 

(Japanese 

legal) 

landscape — 

JIS 

B5 

(Japanese 

letter) 

portrait — 

JIS 

B5 

(Japanese 

letter ) 

landscape — 

—  ANSI  legal  portrait — 

—  ANSI  legal  landscape — 
—  ANSI-A  portrait' — 

—  ANSI-A  landscape— 

—  ANSI-B  portrait — 

—  ANSI-B  landscape — 
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DEFINE ( GRAPHICRENDITIONS , " 

{ 'cancel' | 'increased-intensity ' 
' 'italicised' | 'underlined' j 'croased-out' 
'priaiary-font '  |  'first-alternative-font' 
'second-alternative-font'  'third-alternative-font' 
' fourth-alternative-font '  ' fifth-alternative -font ' 
'sixth-alternative -font' | 'seventh-alternative-font' 
'eighth-alternative-font' j 'ninth-alternative-font' 
'doubly -under lined' j 'normal-intensity 
'not-italicised' j 'not -under lined' | 'not-crossed-out'} 
") 

—  Macro  defining  permissible  code  extension  announcers. 
Note  that  all  the  values  are  basic.  — 


DEFINE (COEXTEN, 


ESC  02/00  05/00, 
[ESC  02/00  05/03], 
[ESC  02/00  05/05], 
[ESC  02/00  05/07], 
[ESC  02/00  05/10], 
[ESC  02/00  05/11] 
") 


LSO  — 
LSRl  — 
LSR2  — 
LSR3  — 

552  — 

553  — 


~  Macro  defining  code  extension  announcers  for  profile  default  values  — 

DEFINE ( DAP-DEFAULT-CDEXTEN ,   " SCDEXTEN" ) 

—  Macros  defining  final  character  for  designation  — 

DEFINE  (FCORE,     ••04/02  —  A  final  character  designating  IS0-IR6 

(the  IRV  of  ISO  646  revised  1991,  i.e  ASCII)  — -) 

DEFINE(F646,      ••—  a  final  character  designating  any  version  of  ISO  646 

except,  ISO-IR6  — ") 


DEFINE (F94S,      ••—  a  final  character  designating  any  registered  94  single 

byte  graphic  character  set  optionally  preceded  by  one  or 
more  intermediate  characters  as  defined  in  Annex  C  of 
ISO  2022 — ") 


DEFINE (F94M,      •• —  a  final  character  designating  any  registered  94  multi 

byte  graphic  character  set  optionally  preceded  by  one  or 
more  intermediate  characters  as  defined  in  Annex  C  of 
ISO  2022—") 


DEFINE(F96S,      •• —  a  final  character  designating  any  registered  96  single 

byte  graphic  character  set  optionally  preceded  by  one  or 
more  intermediate  chsuracters  as  defined  in  Annex  C  of 
ISO  2022--") 
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DEFINE(F96M,      " —  a  final  character  designating  any  registered  96  multi 

byte  graphic  character  set  optionally  preceded  by  one  or 
more  intermediate  characters  as  defined  in  Annex  C  of 
ISO  2022  — ") 

DEFINE  (FEMPTY,  "07/14    —  the  empty  set  — ") 

—  Macros  defining  a  Revision  Number  of  a  character  set  — 

DEFINE  (REV,  " —  An  octet  between  04/00  and  07/14  which  represents  a 
I     revision  number  as  defined  in  ISO2022  — ") 

— -  Macros  defining  designation  sequences  — 

DEFINE (DEG-CORE -GO,      "ESC  02/08  $FCORE") 

—  Designate  the  94  characters  of  IS0-IR6  (the  IRV  of 
ISO  646  revised  1991)  to  GO  — 

DEFINE(DEG-646-G0,        "ESC  02/08  $F646") 

—  Designate  any  version  of  ISO  646,  except  ISO-IR6, 
to  GO  —  , 


DEFINE  (DEG-ANY-Gl , 


'{  ESC  02/06  REV]   {ESC  02/09  $F94S 
ESC  02/04  02/09  SF94M 
ESC  02/13  $F96S 
ESC  02/04  02/13  $F96M]}}") 
—  Designate  any  chciracter  set  to  Gl 


DEFINE  ( DEG-ANY-G2 ,        "  { 


DEFINE  ( DEG-ANY-G3  , 


DEFINE  ( DEG-EMPTY-Gl , 


ESC  02/06  REV]   {ESC  02/10  $F94S 
ESC  02/04  02/10  $F94M 
ESC  02/14  $F96S 
ESC  02/04  02/14  $F96M]}}") 

—  Designate  any  character  set  to  G2 

'{  ESC  02/06  REV]   {ESC  02/11  $F94S 
ESC  02/04  02/11  $F94M 
ESC  02/15  $F96S 
ESC  02/04  02/15  $F96M]}}") 

—  Designate  any  character  set  to  G3 

"ESC  02/09  $FEMPTY") 

—  Designate  the  empty  set  to  Gl  — 


I 
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—  Macro  defining  permissible  graphic  character  sets.  — 

DEFINE (PERMIT-GRCHAR,      "     {$DEG-CORE-G0  $-LSO 

|$DEG-646-G0  §-LSO), 
{{$DEG-ANY-<31  $-LSlR 
$DEG-ANY-G2  $-LS2R 
$DEG-ANy-G3  $-LS3R} . . . 
I $DEG-EMPTy-Gl  $-LSlR}  ") 

—  Macro  defining  graphic  character  sets  for  DAP  defaults  - 


DEFIKE  (  DAP-DEFAULT-GRCHAR,    "  SPERMIT-GRCHAR"  ) 


—  Macro  defining  basic  cheuracter  sets.  Note  that  this  macro  is  defined 
for  clarification  of  the  specification  and  is  not  used  in  any 
other  part  of  this  DAP  specification.  — 

DEFINE (BASIC-GRCHAR,    "     $DEG-CORE-G0  $CF-LSO, 

$DEG-EMPTy-Gl  $CF-LSlR  ") 

—  Macro  defining  non-basic  graphic  character  sets  — 

DEFINE (NON-BASIC-GRCHAR,      "  {$DEG-646-G0 

$DEG-ANY-G1 
$DEG-ANY-G2 
$DEG-ANY-G3} . . .  ") 

—  Macro  defining  character  sets  used  in  document  profile  attributes  — 

DEFINE (PROFCHAR,  " 
ESC  02/00  04/03  —  announcement  of  use  of  GO  and  Gl,  and 

invocation  into  GL  and  GR  respectively,  (no  shift 

function  are  necesseiry)  — 
{$DEG-CORE-G0|$DEG-646-G0}    —  designate  GO  — 
{SDEG-ANY-Gl|$DEG-EMPTY-Gl}   —  designate  Gl  — 

—  Macro  defining  comments  chauracter  sets  — 


DEFINE ( COMCHAR, " 

—  in  the  case  to  use  both  GL  and  GR  without  shift  functions  — 

ESC  02/00  04/03  —  announcement  of  use  of  GO  and  Gl,  and 

invocation  into  GL  and  GR  respectively,  (no  shift 
functions  are  necessary.)  — 

{§DEG-CORE-G0|$DEG-646-G0}    —  designate  GO  — 

{$DEG-ANY-Gl|§DEG-EMPTY-Gl}  —  designate  Gl  — 

—  in  the  case  of  use  of  various  character  sets  (shift  functions  are 
necessary) 

{ESC  02/00  05/00,  —  announcement  to  use  GO  and  LSO  — 

[ESC  02/00  05/03],  —  announcement  to  use  Gl  and  LSlR  — 

[ESC  02/00  05/05],  —  announcement  to  use  G2  and  LS2R  — 

lESC  02/00  05/07],  —  announcement  to  use  G3  and  LS3R  — 

[ESC  02/00  05/10],  —  announcement  to  use  G2  and  SS2  — 

[ESC  02/00  05/11]       }  —  announcement  to  use  G3  and  SS3  — 

{$DEG-CORE-G0|$DEG-646-G0}     —  designate  GO  — 


80 


FOD26  Part  1  -  Document  J^pllcation  Profile 


July  1992 


{$DEG-ANY-<31  —  designate  Gl  — 

$DEG-ANY-G2  —  designate  G2  — 

$DEG-ANY-G3}. . .  —  designate  G3  — 

$DEG-EMPTY-G1} 

j   —  Macro  defining  character  sets  used  for  alternative  representation  — 
|dEFIME(ALTCBAR,  "$PR0FCBAR'') 

7.2.2    Constituent  constraints 
7.2.2.1    DocuBientProfile  { 
CASE  $DAC  OF  { 

$FDA:        PERM    Generic-layout-structure  {'factor-set'}, 
PERM    Specif ic -layout- structure  {'present'}, 

—  shall  be  present  in  the  case  of  complete  document  — 

—  and  shall  not  be  present  in  the  case  of  generic  document  - 
PERM    Presentation-styles  {'present'} 

$PDA:       PERM    Generic-layout-structure  {'complete-generator-set'}, 
PERM    Generic -logical-structure      {  'complete-generator  -set 

I  partial-generator-set ' } , 

—  shall  be  present  if  there  is  no  external  document  class 
reference  — 

PERM    specific-logical-structure    { 'present ' } , 

—  shall  be  present  in  the  case  of  complete  document  — 
--  and  shall  not  be  present  in  the  case  of  generic  document  — 
PERM    Presentation-Styles  {'present'}, 
PERM    Layout-styles  {'present'} 

$FPOA:      PERM    Generic -layout-structure  {'complete-generator-set'}, 

—  shall  be  present  if  there  is  no  external  document  class 
reference  — 

PERM    specific-layout-structure  {'present'}, 

—  shall  be  present  in  the  case  of  complete  document  — 

—  and  shall  not  be  present  in  the  case  of  generic  document  — 
PERM    Generic-logical-structure  {'complete-generator-set'}, 

—  shall  be  present  if  there  is  no  external  document  class 
reference  — 

PERM    specific-logical-structure    { 'present ' } , 

—  shall  be  present  in  the  case  of  complete  document  — 

—  and  shall  not  be  present  in  the  case  of  generic  document  — 
PERM    Presentation-styles  {  'present ' } , 
PERM    Layout-styles  {'present'} 

> 

PERM  External-document-class  {ANY__VALUE}, 
PERM    Resource -document  {ANy_VALUE}, 
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PERM  Rttflourcas 


{MUL{REQ  #reBource-identifier  {ANY_VALUE), 
R£Q  #resource-ob ject-class-identi£ier 

{ANY_V2^UE)}}, 


—    docuflwnt  char actaria tics  — 

RZQ     Dociunant-application-profile    { — see  clause  8  for  a  definition  of 

the  permitted  values  for  this 
attribute — } , 

PERM    Docuraent-application-profile-defaults  { 


CASE  $DAC  OF  { 

$FDA  t{PERM 
$PDA  : {PERM 
$FPDA  :{PERM 

PERM  tdiaensions 


PERM  tmedium-type 


#content-architecture-class     {$FC | $FPC} } 
icontent-architecture-class     { $FC  $PC | $FPC} } 
♦content-architecture -class     {$FC  SFPC}} 


{REQ  fhorizontal-dimension 

{REQ  # fixed-dimension  '{<=14030}}, 
REQ  ivertical-dimension 

{REQ  # fixed-dimension  {<=19840} 

—  up  to  ISO  A3  portrait  — 
I {REQ  #horizontal-dimension 

{REQ  #fixed-dimension  {<=19840}}, 
REQ  ivertical-dimension 

{REQ  # fixed-dimension  {<=14030} 

—  up  to  ISO  A3  landscape  — 
I {REQ  fhorizontal-dimension 

{REQ  tfixed-dimension  {<=13200}}, 
REQ  ivertical-dimension 

{REQ  ifixed-dimension  {<=20400} 

—  up  to  ANSI-B  portrait  — 
I {REQ  ihorizontal-dimension 

{REQ  ifixed-dimension  {<=:20400}}, 
REQ  ivertical-dimension 

{REQ  ifixed-dimension  {<=13200}}} 

—  up  to  ANSI-B  landscape  — }, 

{PERM  inominal-page-size{$NominalPagesizes} , 
PERM  iside-of -sheet  {ANy_VALUE}}, 


PERM    ipage-position  {ANY_value}, 

PERM    tlayout-path         { '0-degrees '  |  '  180-degrees '  |  '270-degrees ' } , 


PERM    itype-of -coding    {ASN.1{2  8  3  6  0} 

ASN.1{2  8  3  7  0} 

ASN.1{2  8  3  7  1} 

ASN.1{2  8  3  7  2} 


character  encoding  — 
T,6  encoding  — 
T.4  one  dimensional 

encoding  — 
T.4  two  dimensional 

encoding  — 
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ASN.1{2  8  3  7  3}  —  bitmap  encoding  — 
ASN.1{2  8  3  8  0}  —  geometric  encoding  — }, 


PERM  fcharacter-content -defaults  { 


PERM 

iaiunent 

/ANY  VALUE 1 

PERM 

/AMY  VAI.tIE\ 

PERM 

i  c  H  Ap  AC     1?  «*D  a.'t  h 

/ANY  VA1.UE\ 

PFPM 

PERM 

/  SDAP— DEFAULT— CDEX"rEM\ 

PERM 

#f irflt— line— of f set 

/ANY  VAIiUEl  - 

PERM 

^graphic— character— sets 

/SDAP-DEFAULT-GRCHARl . 

PERM 

iaraDhic— character —subreDertoiire 

/ANY  VALUE 1  - 

PERM 

i  cTP&nH  j_c  —rendition. 

/Sgraphicrenditions\ - 

PERM 

#  indentation 

/ANY  VAIiUEl . 

PERM 

#initial-of f set 

{ANY  VALUE}, 

PERM 

#itemisation 

{ANY_VALUE}, 

PERM 

#kerning-of f set 

{ANY_VALUE}, 

PERM 

#line-layout-table 

{ANY_VALUE}, 

PERM 

# line -pr ogre s  s ion 

{ANY_VALUE} , 

PERM 

#line-spacing 

{ANY_VALUE}, 

PERM 

#orphan-size 

{ANY_VALUE}, 

PERM 

#proportional-line-spacing 

{ANY_VALUE}, 

PERM 

#widow-size 

{ANY_VALUE}}, 

PERM  fraster-graphic-content-defaults  { 
PERM  #c lipping 
PERM  #image-dimensions 
PERM  #pel-spacing 
PERM  # spacing-ratio 
PERM  tcompression 


ANY_VALUE}, 
ANY_VALUE}, 
ANY_VAHJE}, 
ANY_VALUE}, 
ANY__VALUE}}}, 


REQ  Document-architecture-class 
REQ  Content-aurchitecture-classes 
REQ     Interchange -format 


{$fda|$pda|$fpda}, 

{  [$FC]  ,  [$PC1  a$FPC]  ,  t$FPRl  ,  [$FPG1  }  , 


REQ  Oda-version 


—  See  clause  8  for  a  defintion  of 

the  permitted  values  for  this  profile 

{REQ  #standard-or-recommendation{"ISO  8613"}, 
REQ  #publ ic at ion-date {1992-05-01}}, 


—  non  basic  document  characteristics  — 
PERM    Profile-character-sets  {$PROFCHAR}, 
PERM    Comments -character-sets  {$COMCHAR}, 
PERM    Alternative-representation-character-sets  {$ALTCHAR}, 
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PERM    Pagd-dimeneiona  {PMUL 

{REQ  ihorizontal-dimension 

{REQ  # fixed-dimension  {<»14030>}, 
REQ  tvertical-dimension 
{REQ  ffixed-dimenaion  {12401. .19840}} 
I {REQ  thorizontal -dimension 

{REQ  # fixed-dimension  {9241. .14030}}, 
REQ  tvertical-dimension 
{REQ  tfixed-dimension  {<*19840}} 
—  Up  to  ISO  A3  portrait  — 

I {REQ  thorizontal-dimension 

{REQ  tfixed-dimension  {12401. .19840}}, 
REQ  tvertical-dimension 
{REQ  tfixed-dimension  {014030}} 
I {REQ  thorizontal-dimension 

{REQ  tfixed-dimension  {<>19840}}, 
REQ  tvertical-dimension 
{REQ  tfixed-dimension  {9241. .14030}} 

—  up  to  ISO  A3  landscape  — 

I {REQ  thorizontal-dimension 

{REQ  tfixed-dimension  {<«13200}}, 
REQ  tvertical-dimension 
{REQ  tfixed-dimension  {12401. .20400}} 
I {REQ  thorizontal-dimension 

{REQ  tfixed-dimension  {9241. .13200}}, 
*         REQ  tvertical-dimension 

{REQ  tfixed-dimension  {<*:20400}} 

—  up  to  ANSI-B  portrait  — 

I {REQ  thorizontal-dimension 

{REQ  tfixed-dimension  {12401. .20400}}, 
REQ  tvertical-dimension 
{REQ  tfixed-dimension  {<>13200}} 
*  ;  I {REQ  thorizontal-dimension 

{REQ  tfixed-dimension  {<>20400}}, 
1  REQ  tvertical-dimension 

{REQ  tfixed-dimension  {9241. . 13200}}  } 

—  up  to  ANSI-B  landscape  —  }, 

—  any  value  of  dimensions  which  is  greater  than  the  common  assured 
reproduction  area  of  ISO  A4  and  ANSI-A  is  non-basic  — 

PERM    Medium-types  {PMUL 

{PERM  tnominal-page-size{$NominalPageSize8} , 
PERM  tside-of-sheet{ 'recto' I 'verso'}}}, 
—  all  values  of  "medium  type"  are  non-basic  ~ 

PERM    Layout-paths        {{ '0-degrees' | '90-degrees' | ' ISO-degrees '}.. .}, 

PERM    Borders  {ANY_VALUE} , 

PERM    Coding-attributes  { 
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PERM    #raater-graphics-coding-attributes  { 
PERM  fcompression 


{ 'uncompressed' } } } , 


PERM    Presentation-features  { 

PERM  tcharacter-presentation-features 
PERM  icharacter-orientation 
PMUL  {PERM  #character-path 


PMUL  {PERM  fcharacter-spacing 


{ 


{ '90-degrees'), 
{ '90-degrees' 
' 180 -degrees ' 
'270-degrees'>}, 

{<100|l00|l60|200}}, 
-only  values  <100  are  required 
to  be  specified.    Values  100,  160 
200  may  be  specified  here  for 
upwards  compatibility  from  FODll— 


PMUL  {PERM  #graphic -character-sets  {$NON-BASIC-GRCHAR}}, 
PMUL  {PERM  tgraphic-character- 

subrepertoire  {ANY_VALUE)) , 

PMUL  {PERM  #graphic-rendition  { 'crossetd-out' 

I 'not-crossed-out' }} , 
—  values  need  not  be  declared.    Only  permitted  for  upwards 

compatability  from  FODll  — 
PMUL  {PERM  #line-spacing 


{ANY_VALUE) 
EXCEPT{200,300,400}, 


~  value  150  need  not  be 

decleured,  the  value  may  be 
specified  here  for  upwards 
compatability  from  FODll  — 


PERM  tline-progression 


{ ' 9  0-degrees ' } } , 


PERM  fraster-graphics-presentation-feati^res  { 
PMUL  {PERM  #pel-spacing  {ANY_VALUE} 

EXCEPT{16,12,8,6,5,4,3,2,1>, 

—  Any  value  of  #pel  spaces  is  permitted  as  basic  — 

—  Basic  values  of  #length  are  multiples  of  #pel  spaces  as  listed  — 


—  additional  document  characteristics  — 


PERM    Fonts -list 


{PMUL{REQ  # font-identifier  {ANY_VALUE}, 
REQ  #font -reference  {ANy_yALUE))), 


—  document  management  attributes  — { 


—  document  -description  — 

PERM  Title 

PERM  Subject 

PERM  Document -type 

PERM  Abstract 

PERM  Keywords 

REQ  Document -reference 


{ANY_STRING} , 
{ANY_STRING} , 
{ANY_STRING} , 
{ANY_STRING} , 
{ANY_STRING. . 
{ANY_VALUE}, 
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— •  dates  and  times  — 
PERM  Document-date-and-time 
PERM  Creation-date-and-time 
PERM  Local-filing-date-and-tina 
PERM  Expixy-date-and-time 
PERM  start-date-and-time 
PERM    Purge-date -and-tiste 
PERM  Release-date-and-time 
PERM  Revision-history 


{ANy_STRIHG}  , 
{ANY__VALUE}, 
{ANY_STRINS> , 
{ANY~STRIHG} , 
{ANy"sTRING> , 
{ANY_STR1NG} , 
{ANy~STRING> , 

{any"value}. 


—  originators  — 
PERM  Organizations 
PERM  Preparers 
PERM  Owners 
PERM  Authors 


{ANY^STRING. . 
{ANY~VALUE}, 
{ANy__VALUE), 
{ANY_VALUE), 


—  Other  user  information  — 
PERM  Copyright 
PERM  status 

PERM  User-specific-codes 
PEim  Distribution-list 
PERM  Additional-information 


{ANY_VALUE}, 
{ANY_STRING} , 
{ANY_STRING. . 
{ANY__VALUE)  , 
{ANY_VALUE), 


~"  external  references  — 
PERM  References-to-other-documents 
PERM  Superseded-documents 


{ANY_VALUE}, 
{ANY_VALUE} , 


—  local  file  references  — 
PERM  Local-file-references 


{ANY_VALUE) , 


—  content  attributes  — 
PERM  Document-size 
PERM  Number-of-pages 
PERM  Languages 


{ANy_INTEGER} , 

{any'integer} , 
{amy~strihg...>, 


~  security  information  ~ 
PERM  Authorization 
PERM  Security-classification 
PERM    Access -rights 


{ANY_VALUE) , 
{ANY_STRING}  , 
{ANY^STRING. . .}) 


7o3  Logical  constituent  conBtrain1:a 
7.3.1    Macro  definitions 


DEFINE ( DocLogRootGFS , 
<construction-expr> 


<construction-term> 


: <construction-term> 
I <construction-type>; 

: ! »  <con8truction-f actor> 

OPT  <construction-f actor> 
REP  <construction-f actor> 
OPT  REP  <construction-factor> 
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<conatruction<-type> 


<con8truction-factor> 


SEQ( {<conatruction-tenn>} . , . ) 
|CHO( {<conatruction-tenn>} . . . ) ? 

OB JECT_CIASS_ID_OF ( Paa  sage ) 
j  <con8truction-type>; 


DEFINE  ( CONSTRAINT- 1 , 
<con8traint-l> 


<con8truction-tenn> 


<con8truction-type> 


<con8truction-£actor> 


<construction-term> 
I <con8truction-type>; 

t:«  <con8truction-factor> 

OPT  <construction-f actor > 
REP  <construction-f actor> 
OPT  REP  <con3truction-f actor >; 

SEQ( {<construction-tenn>} . . . ) 
I CHO( {<construction-tenn>} . . . ) « 


OB JECT_CLASS_ID_OF ( Paragraph ) 
OB JECT_CLASS_ID_OF ( BodyText ) 
OB JECT_CLASS_ID_OF ( BodyRaster ) 
OB JECT_CLASS_ID_OF ( BodyGeometric ) 
<cons true tion-type> ; 


DEFINE  ( CONSTRAINT-2  , 
<con8tr  aint-2  > 


OB  JECT_CLASS_ID_OF  ( NumberedSegment ) 
OPT  REP  OBJECT_CLASS__ID_OF( NumberedSegment) 
REP  OBJECT_CLASS_ID_OF( NumberedSegment) 
OPT  OBJECT  CLASS  ID  OF (NumberedSegment ) ; 


DEFINE  (Pa8  8  ageGFS,  * 
<con8truction-expr> 


$C0NSTRAINT-1 
$C0NSTRAINT-2 


) 


:;»  <constraint-l> 
" <constraint-2> 

SEQ  ( <constr aint- Ixcons tr aint-2> ) ; 


DEFINE  (NunberedSegmentGFS , 
<conatruction-expr> 


SEQ(<constraint-3>[<conatraint-l>] 
[<conatraint-2>] ) ; 


<con8traint-3> 

$C0NSTRAINT-1 
$C0NSTRAINT-2 


OBJECT  CLASS  ID  OF (Number); 


DEFINE ( Paragr aphGFS , 
<construction-expr> 


::=  <con3truction-term> 
I <construction-type>; 
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<con8truction-tenn> 


<coR8truction-type> 


<con8truction-£actor> 


1 1< 


:  t) 


<conatruction-factor> 
OPT  <construction-factor> 
REP  <con8truction-f actor > 
OPT  REP  <con8truction-£actor>; 

SEQ( {<con8truction-tenn>} . . . ) 
I CBO( {<con8truction-tenD>> . . . ) ; 

OB JECT_CLASS_ID_OF ( BodyText ) 
■  OB JECT_CLASS_ID_OF ( BodyRa8ter ) 
OB  JECT__CIASS__ID_OF  ( BodyGeometric ) 
OB  JECT__CIASS_ID_OF  ( Footnote ) 
<cona truction-type> ; 


DEFINE ( FOOtnoteGFS , 
<construction-expr> 


) 


SEQ  ( OB  JECT__CLASS_ID_OF  ( FootnoteRef  erence ) 
0BJECT__CIiASS_ID_0F(FOOtnoteBody)  ) ; 


DEFINE  ( FootnoteBodyGFS , 
<construction-expr> 


: :  ■  SEQ  ( 0BJECT_CIASS__1D__0F  ( FootnoteNumber 

<con3traint-4>) ; 


<constraint-4> 


::■  OBJECT_CLASS_ID_OF(FootnoteText) 

REP  ( OBJECT_CIiASS_ID_OF  ( FootnoteText )  ) 
CHO(  {OBJECT__CLASS_ID_OF( FootnoteText)  }  .  .  .  ) 
REP  CHO  ( {  OB JECT_CLAS  s__ID_OF  ( FootnoteText ) } 


); 


DEFINE ( CommonContentGFS , 
<con8truction-expr> 


<con8truction-£actor> 


::«  <con8truction-f actor > 

I SEQ(<con8truction-£actor>. . . ) 7 

OBJECT_CLASS_ID_OF(CoininonText) 
OB JECT_CLASS_ID_OF ( PageNumber ) 
OB  JECT__CIjASS__ID__OF  ( CommonRaater ) 
OB JECT_CIiASS_ID_OF  ( commonGeometrlc ) ; 
) 


DEFINE  (N, 

-<n>::«{""0"-|"-l""|""2-"|""3"-|-"4"-|-"5"-|-"6--|"-7""|"-8""|-"9-"). 
—  any  atring  of  characters  from  the  aet  of  characters;  '0'...'9'  — ; 


—  Defines  the  prefix  binding.    Thia  binding  may  be  uaed  to  aaaociate  a  string 
literal  with  an  object  or  object  class.    In  addition,  this  binding  is  used  to 
prefix  text  to  another  binding,  such  as  a  segment  number,  footnote  number  or 
page  number.    The  instances  are  differentiated  by  a  suffix  niunber.  — 
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DEFINE  (PREFIX, 

<pre£ix>      ::»    ""pref  ix-""<n>; 

-) 

—  Defines  the  suffix  binding.  This  binding  may  be  used  to  associate  a  string 
literal  with  an  object  or  object  class,    in  addition,  this  binding  is  used  to 
suffix  text  to  another  binding,  such  as  a  segment  number,  footnote  number  or 
page  number »    The  instances  are  differentiated  by  a  suffix  number.  — > 

DEFINE  (SUFFIX, 

<8uffix>      s:«    ""suf fix-""<n>; 
$N 

") 

— •  Defines  the  separator  binding.  This  binding  is  used  to  provide  a  sepeurator 
character  for  a  hierarchical  form  of  a  segment  number,  footnote  number  or  page 
number.    The  instances  are  differentiated  by  a  suffix  number.  — 

DEFINE  ( SEPARATOR, 

<separator>  "sep2u:ator-"<n>; 
$N 

") 

—  Defines  the  general  number  binding.    This  binding  may  be  instanced  for  use 
as  the  ntimeric  value  for  use  such  as  in  segment  number,  footnote  number  or  page 
number  bindings.    The  instances  are  differentiated  by  a  suffix  number.  — 

DEFINE  (NUMBER,  " 

<nufflber>        ::»    " "number-" "<n>; 

!  $N 

") 

—  Defines  the  general  number  string  binding.    This  binding  may  be  instanced 
for  use  as  the  string  value  such  as  for  segment  number,  footnote  niimber  or  page 
numbers.    The  instances  euce  differentiated  by  a  suffix  number.  — 

DEFINE  ( NUMBERSTRING  ,  " 

<numberstring>  ••••numberstring-""<n>; 

$N 

I  ") 

I  —  Used  to  initialise/specify  any  of  the  bindings,    the  bindings  defined  by 
I  this  macro  are  permitted  to: 

-  any  logical  object  class 

-  any  logical  object 

-  any  layout  object  class  except  frame  classes  and  block  classes,  and 

-  any  layout  object  except  frames  and  blocks  in  the  case  of  FPDA  and  FDA.  — 
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DEFINE ( INITIALISEANY  < 


REQ  #binding-identi£er{$PKEFIX}, 

REQ  #binding-value{ANY__STRING} 
|req  #binding-identifer{$SUFFIX), 

REQ  #binding-value{ANY_STRING) 
I REQ  fbinding-identif er { $SEPARATOR} , 

REQ  #binding-value{ANY_STRING} 
|req  #binding-identi£er{$NUMBER}, 

REQ  #binding-value{{>sO} 
I REQ  #binding-identifer{$NUMBERSTRING} , 

REQ  #binding-value{ANy  STRING} 


Used  to  make  a  simple  or  compound  string  out  of  the  number  bindings.  — 


DEFINE ( USENUMBERSTRINGS , 


<hier archie -expr > 


REQ  #binding-identifer{$NUMBERSTRlNG} , 
REQ  #binding-value{<string-expr>: : =<hierarchic 
-expr> I < s imp le -expr >; } 

:  :=    B__REF(SUP(CURR_OBJ) )  (<numberstring>) 
+B__REF  ( SUP  ( CURR_OB J ) )  ( <8epar ator> ) ) 
•K  s imp le -expr > ; 


<simple-expr> 


$SEPARATOR 

$NUMBER 

> 


MK-STR(B_REF(CURR-OBJ) (<number>) ) 
"u-ALPHA(B_REF(CtJRR-OBJ)  (<number>) ) 

L-ALPHA(B~REF(CURR-OBJ) (<number>) ) 

u-ROM(B_REF(CURR-OBJ) (<number>) ) 

L-ROM(B_REF(CURR-OBJ) (<number>) ) 

MK-STR(ORD(CURR-OBJ) ) 

U-ALPHA(ORD(CURR-OBJ) ) 

L-ALPHA ( ORD ( CURR-OB J ) ) 

U-ROM ( ORD ( CURR-OB J ) ) 

L-ROM( ORD (CURR-OB J) ) ; 


) 


—  Used  to  increment  any  of  the  number  bindings.  — 


DEFINE ( USENUMBERS , 


REQ  #binding-identifer{$NUMBER} , 
REQ  #binding-value 

{<num-expr>: :=INC(B_REF(PREC(CURR_OBJ) ) (<number>) ) ; 


$NUMBER} 


—  This  string  expression  is  allowed  in  a  content  generator  for  Number  to 
automatically  generate  text  for  segment  numbers.  — 
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DEFINE  ( SEGMENTNUMBER, 

<string-expr>  [<pre-at>]<nuin-3t>[<suf-8t>] ; 

<nuin-str>  ::=    B_REF(SUP(CURR_OBJ) )  (<nuinber8tring>) ; 

<pre-st>  : :  =    B_REF ( SUP ( CURR_OB J ) ) ( <pref ix> ) 

|aNY_STRING; 

<8Uf-st>  ::=     B_REF(SUP(CURR__OBJ)  )<<8Uffix>) 

|any_string; 

$numberstring 

$PREFIX£S 
^SUFFIXES 

") 

—  Used  to  initialise  fnotenumber  and  fnotestring  bindings.  — 
DEFINE  ( INITIALISEFNOTE , 

REQ  fbinding-identif er { " " fnotenumber" " } , 

REQ  #binding-value{>=0) 

") 

—  Used  to  increment  fnotenumber  binding.  — 
DEFINE  ( INCFNOTENUMBER , 

REQ  #binding-identifer{ " "fnotenumber" ••} , 
REQ  #binding-value{<nxim-expr>:  :=INC(B_REF(PREC 

(CURR-OBJ) )(" "fnotenumber" "); } 

") 

—  Used  to  create  a  fnotestring  from  a  fnotenumber  binding.  — 

DEFINE  ( FNOTENUMBERSTRING , 

REQ  #binding-identif er { " fnotestring" } , 
REQ  #binding-value{<str-expr>: := 

MK-STR(B_REF( CURR-OBJ)  (""fnotenumber"") ) 
U-ALPHA(B_REF( CURR-OBJ)  (""fnotenumber"") ) 
L-ALPHA(B_REF(CURR-OBJ)  (""fnotenumber"" ) ) 
U-ROM  ( B_REF  ( CURR-OBJ )  ( "  "  fnotenumber  "  " ) ) 
L -ROM (B_REF( CURR-OBJ)  (""fnotenumber"" ) ) ;  } 

") 

i  —  Used  to  reset  the  footnote  number  string  to  a  string  literal.    This  provides 
'  a  mechanism  for  setting  the  footnote  number  string  to  something  other  than  a 
numeric  value.  — 

i 

DEFINE ( FNOTESTRINGLITERAL , 

REQ  #binding-identifer{ "fnotestring" } , 
REQ  #binding-value{ANY_STRING} 
") 

—  This  string  expression  is  allowed  in  a  content  generator  for  FootnoteNumber 
and  FootnoteRef erence  to  automatically  generate  text  for  a  footnote  number.  — 
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DEFINE ( FNOTENUMBER, 

<string-expr>  ::-    [ANY_STRING]<nuin-atr>(ANy_STIlING] ; 

<nuin-str>  .    ;  s »    B__REF  ( SUP  ( CURR_OB J ) )  ( "  "  fnotes tring"  " ) 

") 

DEFINE (PGNUMBERS  ,  " 

<atring-expr>  :i«        (ANy_STRING]  {<num-atr>}  [ANY_STRING] ; 

<num-str>  MK-STR(<nxiineric-expr>) 

U-ALPBA  ( <nuiner  ic -'expr> ) 
L-ALPHA  ( <iMimer  ic -expr> ) 
U-ROM  ( <nuiner  ic -expr  > ) 
L-ROM(<nvuneric-expr>) ; 

<nuineric-exp>  B_REF(SUP(CURR_INST(<clas8-or-typel>, 

(CURR_OBJ) ) ) ) ( " "PGnum" " ) 
I B_REF ( CURR_INST ( <clas s -or-type2 > , 
CURR_OB J ) ) ) ( " "PGnum" " ) ; 

<class-or-typel>    ::=  'frame'; 

<class-or-type2>  'page' 

OB JECT_CLASS_ID_OF ( Page ) 

OB JECT_CLASS_ID_OF ( RectoPage ) 

OB JECT__CLASS_ID__OF  ( Ver soPage ) ; 


7.3.2    Factor  constraints 
7.3.2.1     FACTOR  ANT-LOGICAL  { 
GENERIC : 


REQ 

Object-type 

{VIRTUAL} , 

REQ 

object-class-identifier 

{ANY_VALUE} 

SPECIFIC: 

PERM 

Object-type 

{VIRTUAL}, 

REQ 

object-identifier 

{ANY_VALUE}, 

REQ 

Object-class 

{VIRTUAL} 

SPECIFIC_ 

AND_GENERIC : 

PERM~ 

User-readeUale-comments 

{ANY_STRING} , 

PERM 

User-visible-name 

{ANY_STRING} } 

7.3.3    Constituent  constraints 

7.3.3.1    DocumentLogicalRoot:  ANY-LOGICAL  { 

GENERIC: 

REQ       Object-type  {  '  document-logical-root ' } , 

REQ       Generator-for-subordinates    {$DocLogRootGFS} , 

REQ       Application-comments  {REQ  #constraint-name  {"0"}, 


92 


TOD26  Part  1  -  Document  J^plication  Profile  July  1992 


SPECIFIC : 

PERM  Object-type 

REQ  Object-class 

REQ  Subordinates 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 

PERM  Bindings 


{'document-logical-root'}, 
{ OB JECT_CLASS_ID_OF 

(DocumentLogicalRoot) } , 
{SUB_ID_OF( Passage )+} , 
{REQ  #constraint-name  {"0"}, 
PERM  #external-data  {ANY_VALUE}} 

{PMUL{$INITIALISEANY} , 
PERM{$INITIALISEFNOTE} } } 


7.3.3.2    Passage:  ANY-LOGICAL  { 


GENERIC: 
REQ 
REQ 
REQ 

SPECIFIC : 
'  PERM 
REQ 
REQ 


Object -type 

Generator-f or-subordinates 
Application-comments 


Object-type 

Object-class 

Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Layout-style 
PERM  Bindings 


{ 'composite-logical-object ' } , 
{$PassageGFS} , 

{REQ  #constraint-name  {"l"}, 
PERM  #external-data  {ANY_VALUE}} 

{ ' composite-logical-object ' } , 
{OBJECT_CLASS_ID_OF ( Passage ) } , 
{ SUB_ID_OF ( Number edsegment ) + , 

SUB_ID_OF ( BodyText ) + , 

SUB_ID_OF ( BodyRaster ) + , 

SUB_ID_OF ( BodyGeometr ic ) + , 

SUB_ID_OF ( Paragraph )+}, 
{REQ  #constraint-name  {"1"}, 

PERM  #external-data  {ANY_VALUE}} 

{ STYLE_ID_OF ( L-Sty le 1 ) } , 
{PMUL{$INITIALISEANY} , 
PERM { $ INITIALISEFNOTE } ) 


7.3.3.3    Mujnberedsegment:  ANY -LOGICAL  { 


GENERIC: 
REQ 
REQ 
REQ 


Object-type 

Generator-f or-subordinates 
Application-comments 


{ 'composite-logical-object' } , 
{ $NumberedSegmentGFS } , 
{REQ  #constraint-name  {"2*'}, 
PERM  #external-data  {ANY_VALUE} } , 
{PMUL{$INITIALISEANY} , 
PERM { $USENUMBERS } , 
REQ{ $USENUMBERSTRING} } 

—  The  binding  USE  numbers  shall  also  be  present  if  — 

—  USENUMBERSTRING  does  not  use  the  ORD  option.  — 


REQ  Bindings 


SPECIFIC  s 
PERM 
REQ 
REQ 


Object-type 

Object-class 

Subordinates 


{ ' composite-logical-object ' } , 
{OBJECT_CLASS_ID_OF(NumberedSegment) } , 
{ SUB_ID_OF ( Number ) , 

SUB_ID_OF ( NumberedSegment ) + , 

SUB  ID  OF ( BodyText )+, 
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PERM  Bindings 

PERM  Application-comments 

SPECIFIC__AND_GENERIC : 
PERM  Layout-style 


SUB_ID_OF ( BodyRaster )+, 

SUB  ID_OF ( BodyGeometric ) + , 

SUB_ID_OF  ( Pauragr  aph ) + } , 
{PMUL{$INITIALISEANY} } , 
{REQ  #constraint-name  {"2"), 

PERM  #external-data  {ANy_VALUE}} 

{STyLE_lD_OF {L-Style4 ) } } 


Object-type  { 'basic-logical-ob^ect ' } , 

Content-generator  {$SEGMENTNUMBER} , 

Application-comments  {REQ  Icons traint-name  {"3"}, 

PERM  #external-data  {ANY  VALUE}} 


7.3.3.4    Number:  AKY-LOGICAL  { 

GENERIC : 
REQ 
REQ 
REQ 

SPECIFIC: 

PERM  Object -type 

REQ  object-class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC : 

PERM  Layout-style 

PERM  Presentation-style 

PERM  Content-architecture-class 


{ 'basic-logical-object ' } , 
{OBJECT_CLASS_ID_QF (Number) } , 
{REQ  Icons traint-name  {"3"}, 
PERM  lexternal-data  {ANY_VALUE}} 

{ STYLE_ID_OF ( L-S ty le2 ) } , 
{STYLE~ID_OF(P-Stylel) } , 
{$FC|$PC|$FPC}} 


7.3.3.5    Paragraph:  ANY -LOGICAL  { 


GENERIC : 
REQ 
REQ 
REQ 


REQ 
REQ 


Object-type 

Generator-for-subordinates 
Application-comments 


SPECIFIC: 

PERM  Object-type 
Object-class 


Subordinates 


PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Layout-Style 


{ 'composite-logical-object'}, 
{ $Paragr aphGFS } , 
{REQ  Icons traint-name  {"6"}, 
PERM  lexternal-data  {ANY_VALUE}} 

{ 'composite-logical-object'}, 
{  OB  JECT_CLASS_ID_OF 

(Paragraph) } , 
{ SUB_ID_OF ( BodyText ) + , 

SUB_lD_OF ( Footnote ) + , 

SUB_ID_OF ( BodyRaster ) + , 

SUB_ID_OF ( BodyGeometric ) +} , 
{REQ  Iconstraint-name  {"6"}, 

PERM  lexternal-data  {ANY__VALUE} } 

{STYLE_ID_OF (L-Style4 ) } } 
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7.3.3.6     Bodyrext:  ANY-LOGICAL  { 


GENERIC : 
BEQ 
PERM 
REQ 

SPECIFIC  I 
PERM 
REQ 
PERM 


Object -type 
Resource 

Application-comments 


Object -type 

Object-class 

Application-comments 


SPECIFIC_AND_GENERIC : 
PERM  Layout-Style 
PERM  Presentation-style 
PERM  Content-architecture-class 
PERM      Content -portions 


{ 'basic-logical-object' } , 
{ANY_VALUE}, 

{REQ  #constraint-neune  {"14"}, 
PERM  #external-data  {2lNY_VALUE> } 

{ 'basic-logical-object ' } , 
{OBJECT_CLASS_ID_OF ( BodyText ) > , 
{REQ  #constraint-name  {"14"), 
PERM  #external-data  {ANy_VALUE}} 

{STYLE_ID_0F(L-Style2 ) } , 
{ STYLE_ID_OF ( P-sty le 1 ) } , 
{$FC|$PC|$FPC}, 
{CONTENT_ID_OF( 

Character-content-portion)+} } 


—  if  the  attribute  "content  portions"  is  specified  neither  in  the 
specific  nor  in  the  generic  part  then  the  attribute  "resource" 
shall  be  specified  — 


7.3.3.7    BodyGeometric :  ANY -LOGICAL  { 


GENERIC: 
REQ 
REQ 
PERM 
REQ 

SPECIFIC : 
PERM 
REQ 
PERM 
PERM 


Object-type 

Content-architecture-class 
Resource 

Application-comments 


Object-type 
Object-class 

Content-architecture-class 
Application-comments 


SPECIFIC_AND_GENERIC : 
PERM  Layout-Style 
PERM  Presentation-Style 
PERM  Content-portions 


{ 'basic-logical-object' } , 

{$FPG}, 

{ANY_VALUE}, 

{REQ  #constraint-name  {"18"}, 
PERM  #external-data  {ANY_VALUE}} 

{ 'basic-logical-object ' } , 
{OBJECT_CLASS_ID_OF ( BodyGeometric ) } , 
{$FPG>, 

{REQ  #constraint-name  {"18"}, 
PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_OF (L-Style5 ) } , 
{STYLE_ID_0F(P-Style2 ) } , 
{C0NTENT_ID_OF( 

Geometric -graphics -content -portion) } } 


—  if  the  attribute  "content  portions"  is  specified  neither  in  the 
specific  nor  in  the  generic  paart  then  the  attribute  "resource" 
shall  be  specified  — 
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7.3.3.8    BodyRaater t  ANY -LOGICAL  { 


GENERIC : 
REQ 
REQ 
PERM 
REQ 

SPECIFIC : 
2Em 
REQ 
PERM 
PE^ 


Object -type 

Content-architectur  ©•="€  las  a 
Resource 

App  1  Ic  at  ion-c  osonent  s 


Object-type 
Object-class 

Content -arc hi tecture-c las s 
Application-cossments 


SPECIFIC_AND_GENERIC  : 
PERM  Layout-Style 
PERM  Presentation-Style 
PERM      Content -portions 


{ 'basic-logical-object ' } , 

{$FPR}, 

{ANY_VALUE), 

{REQ  #constraint-naine  {"17"}, 
PERM  #external-data  {ANY_VALUE}} 

{ 'basic-logical-object ' } , 
{OBJECT_CLASS_ID_OF(BodyRaster ) ) , 
{$FPR}, 

{REQ  #constraint-name  {"17"}, 
PERM  #external-data  {ANY__VALUE}} 

{STYLE_ID_OF<L-Style5) }  , 
{STYLE_ID_OF (P-Style3 ) } , 
{  CONTENT__ID__OF  ( 

Raster-graphi,cs-content -portion) }  } 


—  if  the  attribute  "content  portions"  is  specified  neither  in  the 
specific  nor  in  the  generic  part  then  the  attribute  "resource" 
shall  be  specified  — 


7.3.3.9     Footnote:  ANY-LOGICAL  { 


GENERIC: 
REQ 
REQ 

PERM 


SPECIFIC : 
PERM 
REQ 

REQ 

PERM 
CASE 
{REQ 


Object-type 

Generator-for-subordinates 
Bindings 


REQ  Application-comments 


object-type 

object-class 

Subordinates 


{ 'composite-logical -object'}, 
{ $FootnoteGFS } , 

{{$INCFNOTENtJMBER,  $FNOTENUMBERSTRING} 

I $FNOTESTRINGLITERAL} , 
{REQ  #constraint-name  {"8"}, 

PERM  #external-data  {ANY_VALUE}} 

{ 'composite-logical-object'} , 
{OBJECT_CLASS_ID_OF  ( Footnote )  } , 
{SUB_ID_OF(FootnoteReference) , 
SUB_ID_OF(FootnoteBody ) } , 
{ $FNOTESTRINGLITERAL} , 


Bindings 

Footnote  (GENERIC:  Bindings)  OF  VOID 

Bindings  {$fnot£stringliteral} , 


PERM  Application-comments 

SPECIFIC_AND_GENERIC : 
PERM  Layout-style 


{REQ  #con3traint-name  {"8"}, 
PERM  #external-data  {J^_VALUE}} 

{STYLE_ID_OF (L-Style7 ) } } 
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7.3.3.10    FootnoteReference:  ANY -LOGICAL  { 


GENERIC : 

REQ  Object-type 

REQ  Content-generator 

REQ  Application-comments 

SPECIFIC : 

PERM  Object-type 

REQ  Object-class 

PERM  Application-comments 

SPECIFIC_AND_GENERIC  I 

PERM  Layout-style 

PERM  Presentation-Style 

PERM  Content-architecture-class 


{ 'basic-logical-object ' } , 
{$FNOTENUMBER}, 
{REQ  #constraint-name  {"10"}, 
PERM  #external-data  {ANY_VALUE)} 

{ 'basic-logical-object ' } , 
{OBJECT__CLASS_ID_OF 

(FootnoteReference) } , 
{REQ  #constraint-name  {"10"}, 
PERM  #external-data  {ANY_VALUE}} 

{STYLE_ID_OF(L-Style2 ) } , 
{ STYLE_ID_OF ( P-Sty le 1 ) } , 
{$FC|$PC|$FPC}} 


7.3.3.11    FootnoteBody:  ANY -LOGICAL  { 


GENERIC: 
REQ 
REQ 
REQ 


Object-type 

Generator-for-subordinates 
Application-comments 


PERM  Layout-style 

SPECIFIC: 

PERM  Object-type 
REQ  Object-class 
REQ  Subordinates 


PERM 

PERM 
> 


Application-comments 
Layout-style 


{ 'composite-logical-object ' } , 
{$FootnoteBodyGFS} , 
{REQ  #constraint-name  {"11"), 
PERM  #external-data  {ANY__VALUE}} 
{  STYLE_ID__OF  ( L-S ty le  11)} 


{ 'con^osite-logical -object ' } , 

{ OB JECT_CLASS_ID_OF( FootnoteBody ) } , 

{ SUB_ID_OF ( FootnoteNumber , 

SUB_ID_OF ( FootnoteText ) + } , 
{REQ  #constraint-name  {"11"}, 

PERM  #external-data  {ANY__VALUE}}} 
{  STYLE__ID_OF   ( L-Sty le  11)} 


7.3.3.12    FootnoteNumber:  ANY -LOGICAL  { 


GENERIC : 
REQ 
REQ 
REQ 

REQ 

SPECIFIC : 
PERM 
REQ 
PERM 


Object-type 

Content-generator 

Application-comments 

Layout-style 


object-type 

Object-class 

Application-comments 


PERM  Layout-Style 


{ 'basic-logical-object'}, 
{$FNOTENUMBER}, 
{REQ  tconstraint-name  {"9"}, 
PERM  #external-data  {ANY_VALUE}} 
{STYLE_ID_OF(L-Style9 ) } 


{ 'basic-logical-object ' } , 
{OBJECT_CLASS_lD_OF (FootnoteNumber) } , 
{REQ  Iconstraint-name  {"9"} 
PERM  #external-data  {ANY_VALUE} } , 
{STYLE__ID_OF  (L-Style9 )  } 
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SFEciFic^mDjsEmmc  % 

PERM  Present&tioR-style 

PEEK  Content"'©rchitect5ar©-elass 


{  STlfLl_ID_©F  ( F»Sty le  1 )  } , 

{$Fcl$icl$FPC}} 


GENERIC  % 


Object-typ© 
Application-G' 


nts 


REQ  Layout-style 


object "type 
Ob ject-clasa 
Content -portions 


SPECIFIC : 

PERM 

REQ 


PERM  Applicati0n"e©aments 

PERM  Layout-Style 

SPECIFIC__AND_GENERIC  s 

PERM  Presentation-Style 

PERM  Content-architecture-class 

7,3,3,14  CeramonConteat  { 

GENERIC  % 


{ "basie-logical-ob ject ' } , 
{REQ  tconstraint-name  {"12"}, 
PERM  #external-data  {ANY_VALUE}}, 
{STYLE_ID_0F(L-Style6 ) > 


{ 'basie-logieal-ob ject ' ) , 
{OBJECT_CLASS_iD_OF ( FootnoteText ) } , 
{CONTENT_ID_OF( 

Character -content -portion) +) ) , 
{REQ  #constraint-naine  {"12"), 
PERM  #external-data  {ANY_VALUE) } , 
{STYLE_ID_0F(L-Style6 ) } 


{ STYLE_ID_©F ( P-Sty le 1 ) } , 
{$FC|$PC|$FPC}} 


REQ 

Object-type 

{ "composite-logieal-object'}. 

REQ 

Object-class-identifier 

{ANy_VALUE}, 

REQ 

Generator-for-subordinates 

{ $CommonContentGFS } , 

REQ 

Application-comments 

{REQ  #constraint-name  {"19"}, 

PERM  #external-data  {ANY_VALUE}}, 

PERM 

User-readedsle-comments 

{ANY_STRING} , 

PERM 

User-visible-name 

{ANY^STRING) > 

.3.15 

CommonText  { 

GENERIC : 

REQ  Object-type 

REQ  Object-class-identifier 

PERM  Content -portion 

PERM  Resource 

PERM  Layout-Style 

PERM  Presentation-Style 

PERM  Content-architecture-clasj 

REQ  Application-comments 


PERM  User-readable-comments 
PERM  User-visible-name 


{ 'basic-logical-object ' } , 

{ANY__VALUE}, 

{  CONTENT_ID__OF  (  ^ 

Character  content-portion ) + } , 
{ANY__VALUE} ,  ^ 
{STYLE_ID_0F(L-Style3 ) } , 
{STYLE_ID_OF (P-Style4 ) } , 
{$FC|$PC|§FPC}, 
{REQ  #constraint-name  {"20"}, 
PERM  #external-data  {ANY_VALUE}}, 

{ANY_STRING} , 

{MTY^STRING}} 


—  either  the  attribute  "content  portions*  or  "resource"  shall  be  specified 

in  the  above  constituent  — 
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7.3.3.16    PageHuiaber  { 


GENERIC : 

BEQ  Object-type 

BEQ  Object-class-identifier 

REQ  Content-generator 

PERM  Layout-style 

PERM  Presentation-style 

PERM  Content-architecture-class 

REQ  Application-comments 

PERM  User-readedsle-comments 

PERM  User-visible-name 


{ 'basic-lcgical-ob ject ' ) , 
{ANY_VALUE), 
{$PGNUMBERS}, 
{STYLE_ID_0F(L-Style3 ) } , 
{STYLE_ID_0F(P-Style4 ) } , 
{$FC|$PC|$FPC}, 
{REQ  icons traint -name  {"40"}, 
PERM  #external-data  {ANY_VALUE}}, 
{ANY__STRING}  , 
{ANY_STRING} } 


7.3.3.17    CommonGeometric  { 


GENERIC : 

REQ  Object-type 

REQ  object-class-identifier 

PERM  Content -portions 

PERM  Resource 

PERM  Layout -style 

PERM  Presentation-style 

REQ  Content-aurchitecture-class 

REQ  Application-comments 


PERM  User-readeJsle-comments 
PERM  User-visible-name 


{ 'basic-logical-object ' } , 

{ANY_VALUE}, 

{C0NTENT_ID_0F( 

Geometric-graphics-content -portion) } , 

{ANY_VALUE), 

{STYLE_ID_OF (L-Style8 ) } , 
{STYLE_ID__0F(P-Style2  )  } , 
{$FPG}, 

{REQ  #constraint-name  {"22"}, 
PERM  #external-data  {ANY_VALUE} } , 

{ANY_STRING}, 
{ANY_STRING}} 


—  either  the  attribute  "content  portions"  or  "resource"  shall  be  specified 
in  the  above  constituent  — 


7.3.3.18    CommonRaster  { 


GENERIC 

REQ  Object-type 

REQ  Object-class-identifier 

PERM  Content -portions 

PERM  Resource 

PERM  Layout-style 

PERM  Presentation-style 

REQ  Content-architecture-class 

REQ  Application-comments 

PERM  User-readable-coraments 

PERM  User-visible-name 


{ 'basic-logical-object ' } , 
{ANY_VALUE}, 
{CONTENT_ID__OF  ( 

Raster-graphics -content -port ion) } , 
{ANY_VALUE}, 

{STYLE_ID__OF  (L-Style8  )  }  , 
{STYLE_ID~OF(P-Style3 ) } , 
{SFPR}, 

{REQ  #constraint-name  {"21"}, 
PERM  #external-data  {ANY_VALUE}}, 
{ANY_STRING} , 
{ANY_STRING} } 


—  either  the  attribute  "content  portions"  or 
in  the  eibove  constituent  — 


•resource"  shall  be  specified 
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7.4  Layout  constituent  constraints 
7.4.1    Macro  definitions  ■ 


DEFINE ( DOCLayROOtGFS , 

<con8truction-expr> 


<con8truction-tem> 


<construction-type> 


<cQnstruction-factor> 


DEFINE ( PageSetGFS , 
<con8truction-expr> 


<PageSet-l> 
<PageSet-2> 
<PageSet-3> 


<construction-tenn> 
I <con8truction-type>; 


<construction-factor> 
OPT  <construction-factor> 
REP  <construction-factor> 
OPT  REP  <construction-f actor>; 

SEQ( {<construction-term>} . . . ) 
I CHO( {<construction-term>} . . . ) ; 

OB JECT_CLASS_ID_OF ( PageSet ) 
I <con9truction-type> ;  , 


) 


<PageSet-l> 
<PageSet-2> 
<PageSet-3> 

<SEQ  ( <PageSet-lxPageSet-2> ) 
<SEQ(<PageSet-lxPageSet-3>) ; 

OB JECT_CLASS_ID_OF ( Page ) 
I  OPT ( OB JECT_CLASS_ID_OF ( Page ) ) ; 

REP  ( OB JECT_CLASS_ID_OF  ( Page )  ) 
I  OPT  REP(OBJECT_CLASS_ID_OF(Page) ) ; 

OPT  REP ( SEQ ( OB JECT_CLASS_ID_OF ( RectoPage ) 

OPT(OBJECT_CLASS_ID_OF(VersoPage) ) ) ) 
I  OPT  REP ( SEQ ( OBJECT_CLASS_ID_OF ( VersoPage ) 

OPT (OBJECT_CLASS_ID_OF( RectoPage) ) ) ) 
I  REP ( SEQ ( OBJECT_CLASS_ID_OF ( RectoPage ) 

OPT ( OB JECT_CLASS_ID_OF ( Ver soPage ) ) ) ) 
I  REP ( SEQ ( OB JECT_CLASS_ID_OF (VersoPage ) 

OPT  ( OB JECT__CLASS_ID_OF(  RectoPage )  )  )  ) ; 


DEFINE (PageGFS, 
<con8truction-expr> 


<headerarea> 


<bodyarea> 


SEQ( [<headerarea>]<bodyarea>[<footerarea>] ) 
|<bodyarea>; 

OBJECT_CLASS_ID_OF ( BasicHeader ) 

I OBJECT_CLASS_ID_OF ( Compos IteHeader ) ; 

OB JECT_CLASS_ID_OF ( BasicBody ) 

I  OBJECT_CLASS_ID_OF(VariableCoinpositeBody ) ; 
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<footerarea> 


OBJECT_CLASS_ID_OF  ( BasicFooter ) 

j  OBJECT_CLASS_lD_OF  ( Compos itePooter) ; 


DEFIHE ( VariableCompositeBodyGFS , 


<construction'>expr> 


<construction-tenn> 


<con8truction->type> 


<con8truction-£actor> 


<construction-footnote> 


<construction-term> 
<construction-type> 

SEQ(<construction-term>,  <construction-footnote>) 

SEQ(<con8truction-type>,  <construction-£ootnota>) ; 


<construction-factor> 
OPT  <construction-f actor> 
REP  <construction-f actor> 
OPT  REP  <construction-factor>j 


SEQ( {<construction-term>} . . . ) 
I CHO( {<con3truction-term>) . . . ) » 

OB  JECT_CLASS_ID_OF  ( BasicFloat ). 
OBJECT_CLASS__ID_OF  ( SnakingColumns ) 
OBJECT_CLASS_lD__OF  ( Synchronizedcolumns ) 
<construction-type> ; 

!=  OBJECT_CLASS_ID_OF(FootnoteArea) 

I  OPT  OB JECT__CLASS_ID_0F  ( FootnoteArea ) ; 


) 


DEFINE  ( snakingColunnsGFS , 
<con8truction-expr>        : :' 


SEQ(  {OB JECT_CLASS_lD_OF(Col\iinnVar labia ) } . . . ) 
I  REP  OB  JECT_CLASS_iD_OF  ( Colxunnvariable )  ? 


DEFINE  (SynchronizedColumnsGFS,  " 

<con8truction-expr>       : :  =    SEQ  ( { OB JECT_CLASS_iD_OF  ( ColumnFixed )}...)# 
DEFINE  (HeaderFooterGFS,  " 

<construction-expr>       ::=  <fixed-coinmon-content-£raines> 

I  <variable-cominon-content-£rame3>; 

<fixed-coinnon-content-£r  antes  > 

I : B  SEQ ( {OB JECT_CLASS_ID_OF ( sourcedContentFlxed ) 

I  OB JECT_CLASS_lD_OF  ( Arr angedContentFixed ) } 


); 


<variable-conimon-content-£rames> 

: :  >  SEQ  ( {OBJECT_CLASS_ID_OF  ( SourcedContentVariable ) 

I  OBJECT_CLASS_ID_OF  ( ArrangedcontentV£u:iable  )>...); 


DEFINE  ( PAGENUMBER, 


) 


REQ  tbinding-identif ier{""PGnum""} , 

REQ  tbinding -value  {<num-expr> : ;  =INC  ( B_REF  ( PREC  ( 

CURR-OBJ) ) ( " "PGnum" " ) ) ; } 

•) 


101 


FOD26  Part  1  -  Document  Application  Profile 


July  1992 


DEFINE (INITIALISEPGNUM,  " 

{REQ  #binding-identif ier { " "PGnum" " } , 
REQ  -#binding-value{>=-l}} 
") 

DEFINE (PDA-FPDA,  " {  'processable *  \ ' formatted-proces sable ' } ** ) 


7.4.2    Factor  conatraJLnts 


7.4.2.1     FACTOR  ANY-LAYOUT  { 


GENERIC : 
REQ 
REQ 
REQ 

SPECIFICS 
PERM 
REQ 
CASE 
$FDA: 


Object-type 

Object-class -identifier 
Application-comments 

object -type 
Object-identifier 
$DAC  OF  { 
PERM  Object-class 


$FPDA:  REQ  Object-class 

REQ  Subordinates 
PERM  Application-comments 
SPEC1FIC__AND_GENERIC  : 

PERM  User-readsible-comments 
PERM  User-visible-name 


{VIRTUAL} , 

{ANy_VALUE}, 

{VIRTUAL} 

{VIRTUAL} , 
{ANy__VALUE}, 

{VIRTUAL} 
{VIRTUAL} 

{VIRTUAL} , 
{VIRTUAL} 

{ANY_STRING} , 
{ANY_STRING}} 


7.4.2.2     FACTOR  ANY-PAGE:  ANY-LAYOUT  { 


GENERIC : 
REQ 
CASE 

REQ 
PERM 

SPECIFIC : 
PERM 
REQ 


Object-type 
$DAC  OF  { 
$PDA-FPDA: 

Generator-for-subordinates 
Bindings 

}/ 

Object-type 
Subordinates 


{'page'}, 


{$PageGFS}, 
{$PAGENUMBER} 


{'page'}, 

{ SUB_ID_OF ( BasicHeader ) , 
sUB_lD_OF(CompositeHeader) , 
sUB_ID_OF(BasicBody) , 
SUB_ID_0F ( VariJibleCompositeBody ) , 
SUB_lD_OF(BasicFooter) , 
SUB_lD_OF(CompositeFooter) } 
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SPECIFIC_AND_GENERIC : 
PERM  Dimensions 


PERM    Page -position 


{ {REQ  thorizontal-dimenaion 

{REQ  #f ixed-dimension  {<»14030)}, 
REQ  #vertical-dimenaion 
{REQ  #fixed-diinenaion  {<=19840)}}} 

—  up  to  ISO  A3  portrait  — 
I {REQ  fhorizontal-dimenaion 

{REQ  # fixed-dimension  {<»19840}}, 
REQ  tvertical-dimension 

{REQ  tfixed-dimenaion  {<3l4030}}}, 

—  up  to  ISO  A3  landscape  — 
I {REQ  #hori2ontal-dimension 

{REQ  # fixed-dimension  {<=13200}}, 
REQ  fvertical-dimension 

{REQ  # fixed-dimension  {<=20400)}}} 

—  up  to  ANSI-B  portrait  — 
I {REQ  #horizontal-dimension 

{REQ  #f ixed-dimension  {<=20400}), 
REQ  #vertical -dimension 

{REQ  #f ixed-dimension  {<=13200)}} 

—  up  to  ANSI-B  landscape  — }, 
{ANy_VALUE}} 


7.4.2.3    FACTOR  ANY -FRAME -FIXED:  ANY 

GENERIC: 

REQ  Object-type 
SPECIFIC: 

PERM  Object-type 
SPECIFIC_AND_GENERIC : 

PERM  Position 


PERM  Dimensions 


PERM  Border 


7.4.2.4     FACTOR  ANY -FRAME -VARIABLE: 

GENERIC : 

REQ  Object-type 
SPECIFIC: 

PERM     Object -type 

CASE       $DAC  OF  { 

$FPDA:  REQ  Position 


•LAYOUT  { 


{ ' frame ' } 
{ ' frame ' } 

{REQ  # fixed-position 

{REQ  #horizontal-position  {ANY_VALUE}, 
REQ  #vertical-position  {ANY_VALUE} }} , 
{REQ  #horizontal-dimension 

{REQ  #f ixed-dimension  {ANY_VALUE} } , 
REQ  #vertical-dimension 

{REQ  #f ixed-dimension  {ANY_VALUE} ) ) , 
{ANY_VAHJE}} 


ANY-LAYOUT  { 


{ ' frame ' } 

{ ' frame ' } , 

{REQ  #f ixed-position 

{REQ  #horizontal-po3ition  {ANY_VALUE}, 
REQ  #vertical-position  {ANY_VALUE} }  } , 


i 


103 


F<H>26  Pari:  1  -  Document  Application  Profile 


July  1992 


REQ 


) 


Dimensions       {REQ  fhorizontal-dimension 

{REQ  tfixed-dimension  {AMY__VALUE}}, 
REQ  ivertical-dimension 
{REQ  tfixed-dimension  {ANT^VALUE}}} 


SPECIFIC_AND_GENERIC : 
CASE       $DAC  OF  { 

$FOA:  PERM 


PERM 


PERM 


Border 


Position      {REQ  # fixed-position 

{REQ  thorizontal -position  {ANY_VALUE}, 
REQ  #vertical-position  {ANY_VALUE} } > , 
Dimensions  {REQ  ihorizontal-dimension 

{REQ  tfixed-dimension  {ANY_VALUE}}, 
REQ  tvertical-dimension 

{REQ  tfixed-dimension  {ANY_VALUE}}} 

{ANY^VALUE} 


7.4.2.5     FACTOR  BLOCK  { 


SPECIFIC: 
REQ 
REQ 
PERM 
PERM 


Object-type  {'block'}, 
object-identifier  {ANY  VALUE), 

Content-architecture-class  {$FcJ§FPC | $FPr| $FPG) , 
Presentation-attributes  { 
PERM  tcharacter-attributes  { 
PERM  talignment 
PERM  tcheuracter-fonts 
PERM  tcharacter-spacing 
PERM  tcharacter-orientation 


PERM  tcheuracter-path 


{ANY_VALUE}, 
{ANY__VALUE)  , 
{ANY_VALUE>, 
/'O-degrees' 

90 -degrees'}, 
^  'O-degrees' 
90 -degrees ' } 
ISO-degrees') 
270-degrees'), 
PERM  tcode-extension-announcers  {$CDEXTAN}, 
PERM  tfirst-line-offset  {ANY_VALUE), 
PERM  t graphic -character-sets  {$PERMIT-GRCHAR}, 
PERM  t graphic -char acter-subrepertoire 

{ANY__VALUE}, 

PERM  t graphic -rendition  {$GRAPHICR£NDITIONS}, 
PERM  titemisation  {ANY_VALUE), 
PERM  tkerning-offset  {ANY_VALUE), 
PERM  tline-layout-table  {ANY_VALUE), 
PERM  t line -progress ion  {'90  degrees'] 

PERM  tline-spacing  {ANY__VALUE} , 

PERM  tinitial-offset  {ANY_VALUE})}, 


270-degrees'), 
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PERM  User-readable-conments 
PERM  User-visible-name 
Perm  position 


PERM  Dimensions 


{ANY_STRING) , 
{ANY_STRING} , 
{REQ  # fixed-position 

{REQ  #horizontal-position  {ANY_VALUE), 
REQ  #vertical-position  {ANY_VALUE) ) > , 
{REQ  fhorizontal-dimension 

{REQ  * fixed-dimension  {ANY_VALUE} } , 
REQ  ivertical -dimension 
{REQ  # fixed-dimension  {ANY__VALUE} >}) 


7.4.3    Constituent  constraints 

7.4.3.1    DocumentLayoutRoot:  ANY-LAYOUT  { 

GENERIC : 

REQ       Object-type  {  'document-layout -root ' } , 

CASE       $DAC  OF  { 
$PDA-FPDA: 

REQ  Generator-for-subordinates  {$DocLayRootGFS} ,  . 
PERM      Bindings  {$INITIALISEPGNUM} 

>r 

REQ       Application-comments  {REQ  #constraint-name  {"O"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC: 

PERM    Object-type  { ' document-layout-root ' } , 

CASE     $DAC  OF  { 

$FDA:      PERM    Object-class  {OBJECT_CLASS_ID_OF 

( DocumentLayoutRoot ) } 
$FPDA:     REQ       Object-class  {OBJECT_CLASS_ID_OF 

(DocumentLayoutRoot) } 

}/ 

REQ       Subordinates  {SUB_ID_OF(PageSet)+} , 

PERM     Application-comments  {REQ  #constraint-name  {"0"}, 

PERM  #external-data  {ANY_VALUE))} 


7.4.3.2    PageSet:  AMY-LAYOUT  { 
GENERIC : 

REQ       Object-type  {'page-set'}, 
CASE       $DAC  of  { 
$PDA-FPDA: 

REQ       Generator-for-subordinates    {$PageSetGFS} , 
PERM      Bindings  {$INITIALISEPGNUM} 

)/ 

REQ       Application-comments  {REQ  #constraint-name  {"1"}, 

PERM  #external-data  {ANY_VALUE)} 


1 
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{ 'page-set' ) 


SPECIFICS 

PERM  Object-type 
CASE     $DAC  OF  { 

$FDA:      PERM  -Object-class     {OBJECT_CLASS_ID_OF(PageSet) } , 
§FPDA:    REQ      Object-class     {OBJECT_CLASS_ID_OF(PageSet) } 
}/ 

REQ       Subordinate  s  { SUB_ID__OF  ( Page )  + , 

SUB_ID_OF ( Rec toPage ) + , 
SUB_lD_OF ( VersoPage ) +} , 

PERM     Application-comments  {REQ  icons traint -name  {"1"}, 

PERM  #external-data  {ANY_VALUE)}) 


7.4.3.3    Page:  ANY-PAGE  { 

Application-comments 


GENERIC : 
REQ 


SPECIFIC 
CASE 


{REQ  Icons traint-name  {"2"}, 
PERM  #external-data  {ANY_VALUE}} 


$DAC  OF  { 

$FDAs     PERM    Object-class       {OBJECT_CLASS_ID_OF(Page) } 
$FPDA:  REQ      Object-class       {OBJECT__CLASS_ID_OF(Page) } 
}. 

PERM      Application-comments  {REQ  #constraint-name  {"2"}, 

PERM  #external-data  {ANY_VALUE)) 

SPECIFIC_AND_GENERIC : 

PERM      Medium-type  {PERM  #nominal-page-size 

{ $NominalPageSizes } , 
PERM  #side-of -sheet  {ANY__VALUE}}} 


7.4.3.4    RectoPage:  ANY-PAGE  { 


GENERIC : 
REQ 

REQ 


SPECIFIC: 
CASE 


PERM 
PERM 


Application-comments  {REQ  #constraint-name  {"3"}, 

PERM  #external-data  {ANY_VALUE}), 
Medium-type  {PERM  #nominal-page-size 

{ $NominalPageSize8 } , 
REQ  #side-of-sheet 

{ 'recto' I 'unspecified'}) 

$DAC  OF  { 

$FDA:  PERM  Object-class  { OB  JECT_CLASS_ID_OF(  RectoPage ) } 
$FPDA:  REQ      Object-class      { OB JECT_CLASS_ID_OF( RectoPage ) } 

>r 

Application-comments  {REQ  #constraint-name  {"3"}, 

PERM  #external-data  {ANY_VALUE)}, 
Medium-type  {PERM  #nominal-page-size 

{ $NominalPageSizes} , 
PERM  #side-of-sheet 

{ 'recto' I 'unspecified'}} 
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7.4.3.5    VersoPage:  ANY -PAGE  { 


GENERIC : 
BEQ 

REQ 


SPECIFIC : 
CASE 


PERM 
PERM 


Application-comments 
Medium-type 


$DAC  OF  { 

$FOAt    PERM  Object-class 
$FPDA:  REQ  object-class 
>. 

Application-comments 
Medixim-type 


{REQ  tconstraint-name  {"4"), 
PERM  #oxternal-data  {ANy_VALUE} } , 
{PERM  inominal-page-size 

{ $NominalPageSizes } , 
REQ  #side-o£-sheet 

{ 'verso' j 'unspecified' } } 


{OBJECT_CLASS_ID__OF  ( VersoPage ) } 
{OBJECT_CLASS_lD_OF (VersoPage ) } 

{REQ  #constraint-name  {**4'*}, 
PERM  #external-data  {ANY_VALUE)}, 
{PERM  inominal-page-size 

{ $NominalPageSizes } , 
PERM  #side-of -sheet 

{'verso' I 'unspecified'}}} 


7.4.3.6    BaaicBody:  ANY-FRAME-FIXED  { 

GENERIC : 

PERM  Layout-path 

REQ  Application-comments 
SPECIFIC : 


{ '270-degrees'  —  page  layout  A  — 
'0-degrees'      —  page  layout  B  — 
'180-degrees'  —  page  layouts 

C  and  D  — }, 
{REQ  iconstraint-name  {"28"}, 
PERM  #external-data  {ANY_VALUE}} 


CASE       $DAC  OF  { 

$FDAt  PERM  Object-class  {OBJECT_CLASS_ID_OF(BasicBody) } 
$FPDA:  REQ     Object-class      {OBJECT_CLASS__ID__OF(BasicBody) } 

REQ       Subordinates  {SUB_ID_0F(  specif  icBlock)+}, 

PERM     Application-comments  {REQ  #constraint-name  {"28"}, 

PERM  #external-data  {ANY_VALXJE}}} 
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7.4.3.7    VariableCoB^msiteBocfys  ANY-FRAME -FIJQED  { 


GENERIC: 
CASE 


SPECIFIC: 
CASE 


REQ 


$DAC  OF  { 
$PDA-FPDA: 
REQ  Generator-for-subordinates 

{  $VariableCoinposlteBody6FS} , 


PERM  Layout-path 


REQ  J^plication-cosnoents 


$DAC  OF  { 

$FDA:    PERM  Object-class 

$FPDA:  REQ  Object-clasa 
Subordinates 


PERM  Application-comments 


{'270-degrees'  —  page  layout  A  — 

I'O-degrees'  —  page  layout  B  — 
'180-degrees'  —  page  layouts 

c  and  D  — } 

{REQ  #con8traint-name  {"7"}, 
PERM  #extemal-data  {ANY^VALUE}} 


{  OB  JECT_CLASS_ID_OF 

(VariableCompositeBody ) } , 
{ OB JECT_CLASS_ID_OF 

(VariableCompositeBody) } 

{  sUB_ID_OF  ( Bas  icFloat )  -I- , 
SUB_ID__OF  ( snakingColumns )  , 
SUB_ID_0F  ( synchronizedcolunns )  , 
SUB^ID~OF(FootnoteArea) } , 

{REQ  tconstraint-name  {"7"}, 
PERM  #external-data  {ANY_yALUE}}> 


7.4.3.8    BasicFloat:  ANY-FRAME -VARIABLE  { 


GENERIC : 
CASE 


$DAC  OF  { 
$POA-FPDA: 
REQ  Position 


{REQ  # variable-posit ion  { 
PERM  #o££set  {ANY_VALUE}, 
PERM  fseparation  7any_VALUE}, 
PERM  «alignment  {ANY_VALUE}, 
PERM  «f ill-order  {' normal -order'}}}, 


PERM    Permitted-categories  {ANY_STRING} 

CASE  SUPERIOR  (VeuriableCompositeBody (Layout-path) )  OF  { 
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{'270-degrees'}:  —  page  layout  A  — 

REQ    Dimensions         {req  thorizontal-dimension 

{REQ  # fixed-dimension  {ANY_VALUE}, 
I REQ  #maximum-aize  {'applies')), 
REQ  #vertical-dimension 

{REQ  #rule-b  {ANY_VALUE))), 
PERM  Layout -path        { ' 270-degrees ' ) 
{'0-degrees'):  —  page  layout  B  — 

REQ    Dimensions         {Req  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE))<, 
REQ  #vertical-dimension 

{REQ  # fixed-dimension  {ANY_VALUE) 
I REQ  #maximum-size  { ' applies ' ) ) ) / 
REQ    Layout-path       { '0-degrees') 

{'ISO-degrees'}:  —  page  layouts  c  and  D  — 

REQ    Dimensions  {REQ  #horizontal-dimension 

{REQ  #irule-b  {ANY_VALUE)}, 
REQ  tvertical-dimension 

{REQ  # fixed-dimension  {ANY_VAHJE} 
I REQ  #maximum-size  {'applies'})}, 
REQ    Layout -path       { '18 0-degrees'} 

> 

REQ       Application-comments  {REQ  #constraint-name  {"12"), 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC: 

CASE       $DAC  OF  { 

$FDA:     PERM    Object-class       {OBJECT_CLASS_ID_OF(BasicFloat ) } , 
SFPDA:  REQ      Object-class      {OBJECT_CLASS_ID_OF(BasicFloat) } 

REQ       Subordinates  {SUB_ID_0F  ( Specif  icBlock)+} , 

PERM     Application-comments  {REQ  #constraint-name  {•'12"), 

PERM  #external-data  {ANY_VALUE)}} 

7.4.3.9    SynchronizedColumns:  ANY -FRAME -VARIABLE  { 

GENERIC: 

CASE       $DAC  OF  { 

$PDA-FPDA: 

REQ  Generator-for-subordinates 

{$SynchronizedColumnsGFS} , 

REQ       Position  {REQ  #variable -position  { 

PERM  #offset  {ANY_VALUE}, 
PERM  tseparation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}, 
PERM  #  f  i 11 -order  { ' normal -order ' } } 

CASE  StJPERIOR  (V2a:iableCompositeBody (Layout -path) )  OF  { 
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{ '270-degr8es'} :  —  page 
REQ  Dimensions 


PERM  Layout -path 

{ ' 0-degrees —  page  layout  B  — 

REQ    Dimensions      {REQ  fhorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  ivertical-dimension 

{REQ  # fixed-dimension  {ANY_VALUE} 
I REQ  #maximum-size  { ' applies ' } } } , 
REQ    Layout -path    { ' 0-degrees ' > 

{'180-degrees'}:  —  page  layouts  C  and  D  — 

REQ    Dimensions      {REQ  thorizontal-dimension 

{REQ  #rule-b  {ANy_VALUE}}, 
REQ  tvertical-diiqension 

{REQ  #£ixed-dimension  {ANY^VALUE} 
I REQ  #maximum-8ize  {'applies'}}}, 
REQ    Layout-path    { ' 180-degrees ' } 

} 

)/ 

REQ       Application-comments  {REQ  #constraint-name  {"11"}, 

PERM  #external-data  {ANY_VALUE}} 

SPECIFIC: 

CASE       $DAC  OF  { 

$FDA:    PERM    Object-class  {OBJECT_CLASS_ID_OF 

( synchronizedColumns ) } 
$FPDA:  REQ       object-class  {OBJECT_CLASS_ID_OF 

( SynchronizedColumns ) } 

}, 

REQ       subordinates  { SUB_ID_OF ( ColumnFixed ) + } , 

PERM     Application-comments  {REQ  #constraint-name  {"11"}, 

PERM  #external-data  {ANY_VALUE}}} 


layout  A  — 
{REQ  thorizontal-dimension 

{REQ  «£ixed-dimension  {ANY_VALUE} 
I  REQ  tmeocimum-size  {'applies'}}, 
REQ  ivertical-dimension 

{REQ  #rule-b  {ANY_VALUE}}}, 
{ '270-degrees'} 


7.4.3.10    Snakingcolumns :  ANY -FRAME -VARIABLE  { 

GENERIC : 

CASE       $DAC  OF  { 

$PDA-FPDA: 

REQ    6enerator-for-stibordinates    {$SnakingColumnsGFS} , 
REQ    Position  {REQ  fvariable-position  { 

PERM  foffset  {ANY_VALUE}, 
PERM  tseparation  {ANY_VALUE}, 
PERM  falignment  {ANY_VALUE}, 
PERM  #f ill-order  { 'normal -order'}}, 
PERM  Balance  {ANY_VALUE} 

CASE  SUPERIOR  (VariableCompositeBody (Layout-path) )  OF  { 
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{'270-degree8'}:  —  page  layout  A  — 

REQ    Dimensions      {REQ  thorizontal -dimension 

{REQ  tfixed-dimension  {ANY_VALUE} 
|r£Q  #maximum-aize  {'applies'}}, 
REQ  fvertical-dimension 
{REQ  #rule-b  {ANY_VALUE})}, 
{ ' O-degrees ' I ' ISO-degrees ' } 


REQ  Layout-path 


{ 'O-degrees'} :  —  page  layout  B  — 

REQ    Dimensions      {REQ  #horizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  fvertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE} 
I  REQ  imaximum-size  { ' applies ' } } } , 
{ '90-degree8' I '270-degrees ' } 


PERM  Layout -path 


{ '  180-degrees ' } :  —  page  layouts  C  and  D  — 

REQ    Dimensions      {REQ  fhorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  tvertical-dimension 

{REQ  # fixed-dimension  {ANY_VALUE} 
I REQ  #maximum-size  {'applies'}}}, 
PERM  Layout -path  {'270-degrees'} 


> 

REQ  Application-comments 


SPECIFIC : 
CASE 


REQ 
PERM 


$DAC  OF  { 

$FDA:  PERM 

$FPDA:  REQ 


Object-class 
Object-class 


Subordinates 
Application-comments 


{REQ  #constraint-name  {"10"}, 
PERM  «external-data  {ANY_VALUE}} 


{  OB  JECT_CLASS_ID_OF 

( Snakingcolumns ) } 

{  OB  JECT_CLASS_ID__OF 

( snakingcoliimns ) } 

{  SUB__ID_OF  ( ColumnVariable ) + } , 
{REQ  #constraint-name  {"10"}, 
PERM  #external-data  {ANY_VALUE} } } 


7.4.3.11    ColumnVariable:  ANY -FRAME -VARIABLE  { 

GENERIC: 

CASE       $DAC  OF  { 

$PDA-FPDA: 

PERM    Permitted-categories    {ANY__STRING} , 

REQ      Position  {REQ  #variable-position  { 

PERM  foffset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}, 
PERM  #f ill-order  { 'normal -order '} } 
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CASE  SUPERIOR  (VariedDleCompoaiteBody (Layout -path) )  OF  { 

{'270-degrees'};     —  page  layout  A  — 

REQ    Dimensions       {REQ  fhorizontal-dimension 

{REQ  #£ixed-diinension  {ANy__VALUE}} , 
REQ  fvertical-dimension 
{REQ  #rule-b  {ANY__VALUE} 
I  REQ  tmeocimvun-size  {'applies'}}}, 
PERM  Layout -path      { '270-degrees' } 


REQ 

SPECIFIC: 
CASE 


REQ 
PERM 


{ '0-degrees'} :  —  page  layout  B  — 

REQ    Dimensions       {REQ  fhorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE} 
I REQ  #maximum-size  {'applies'}}, 
REQ  fvertical-dimension 

{REQ  #fixed-dimension  {ANY__VALUE}}}, 
{ '0-degrees'} 


REQ  Layout-path 

{  '  180-degrees ' }  :  —  pstge 
REQ  Dimensions 


REQ  Layout-path 
}/ 

Application-comments 


$DAC  OF  { 

$FDA:    PERM  Object-class 
$FPDA:  REQ  Object-class 
}, 

Subordinates 
Application-comments 


layouts  C  and  D  — 

{REQ  fhorizontal-dimension 
{REQ  frule-b  {ANY_VALUE} 
I REQ  f maximum-size  {'applies'}}, 
REQ  fvertical-dimension 

{REQ  f fixed-dimension  {ANY_VALUE} } } 
{ '180-degrees'} 

{REQ  f constraint-name  {"9"}, 
PERM  f external-data  {ANY_VALUE}}, 


{ OB  JECT__CLASS_lD_OF  ( columnVar  iable ) } 
{OBJECT~CLASS_lD_OF ( ColumnVar iable ) } 

{SUB__ID_0F  ( specif  icBlock)  + ) } , 
{REQ  f constraint-name  {"9"}, 
PERM  f external-data  {ANY__VALUE}}} 


7.4.3.12     ColumnFixeds  ANY -FRAME -VARIABLE  { 


GENERIC : 
CASE 


$DAC  OF  { 
$PDA-FPDA: 


REQ  Permitted-categories  {ANY_STRING} , 
REQ  Position 


{REQ  f fixed-position 

{REQ  f horizontal-position  {ANY_VALUE}, 
REQ  fvertical-position  {ANY_VAHJE}}} 


CASE  SUPERIOR  (VariableCompositeBody (Layout -path) )  OF  { 
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{'270-degrees'}x  —  page  layout  a  — 

REQ    Dimensions      {REQ  thorizontal-dimension 

{REQ  ifixed-dimension  {ANY_VALUE), 
I REQ  fmaximum-size  {'applies}}, 
REQ  fvertical-dimension 
{REQ  #rule-b  {ANY_VALUE} 
I REQ  tmaximmn-size  { ' applies ' } } } , 
PERM  Layout-path  {'270-degree8'} 

< ' O-degrees ' } :  —  page  layout  B  — 

REQ    Dimensions      {REQ  thorizontal-dimension 

{REQ  #rule-b  {ANy_VALUE} 
I  REQ  #maximujn-size  { '  applies ' }  } , 
REQ  fvertical-dimension 
{REQ  ifixed-dimension  {ANY_VALUE} 
I REQ  tmaximum-size  { ' applies '}}}, 
REQ    Layout-path    { '0-degrees'} 

{'180-degrees'}:  —  page  layouts  c  and  D  — 

REQ    Dimensions      {REQ  ihorizontal-c^imension 

{REQ  tmaximum-size  {'applies'}}, 
REQ  fvertical-dimension 
{REQ  f fixed-dimension  {ANY_VALUE} 
I REQ  f maximum-size  { ' applies ' } } , 
REQ    Layout -path  {'180-degrees'} 

> 

REQ       implication-comments  {REQ  f constraint -name  {8**}, 


PERM  f external-data  {ANy__VALUE}} 


SPECIFIC: 

CASE       $DAC  OF  { 


$FDA:     PERM     Object-class  {OBJECT_CLASS_ID__OF 

( Co lumnFixed ) } 

$FPDA:  REQ       Object-class  {OBJECT_CLASS_ID_OF 

(ColumnFixed) } 

>r 

REQ       subordinates  {SUB_ID_OF(  Specif  icBlock)-*-}, 

PERM     Application-comments  {REQ  f constraint-name  {"8"}, 

PERM  f external-data  {ANY^VALUE}}} 


7.4.3.13    FootnoteArea:  ANY-FRAME -VARIABLE  { 

GENERIC: 

CASE      $OAC  OF  { 
$PDA-FPDA: 

REQ     Position  {REQ  fvariable-position  { 

PERM  toff set  {ANY_VALUE}, 

PERM  f separation  {ANY_VALUE}, 

PERM  f alignment  {ANY_VALUE}, 

REQ    f fill-order  {'reverse-order'}}. 
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REQ      Permitted-categories  {"Footnote"} 

CASE  SUPERIOR  (VariableCoo^ositeBody (Layout-path) )  OF  { 

{ '270-degrees'} ;  —  page  layout  A  — 

REQ    Dimensions      {REQ  ihorizontal-dimension 

{REQ  ffixed-dimension  {ANY_VALUE} 
I REQ  #maximum-size  {'applies'}}, 
REQ  tvertical-dimension 

{REQ  #rule>b  {ANY_VALUE}}}, 
PERM  Layout-path    {'270 -degrees ' } 

{'0-degrees'}:  —  page  layout  B  — 

REQ    Dimensions      {REQ  thorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  tvertical-dimension 
{REQ  ffixed-dimension  {ANY_VALUE} 
I REQ  #maximuffl-size  {'applies'}}}, 
REQ    Layout -path    { '0-degrees'} 

{'ISO-degrees'}:  —  page  layouts  C  and  D  — 

REQ    Dimensions      {REQ  ihorizontal-dimension 

{REQ  #rule-b  {ANY_VALUE}}, 
REQ  tvertical-dimension 
{REQ  tfixed-dimension  {ANY^VALUE} 
I REQ  tmaximum-size  { ' applies ' } } } , 
<■  REQ    Layout-path  {'180-degrees'} 

} 

}/ 

REQ       Application-comments  {REQ  tconstraint-name  {"15"}, 


SPECIFIC : 

CASE       $DAC  OF  { 


PERM  texternal-data  {ANY_VALUE}} 


$FDAs    PERM    Object-class      {OBJECT_CLASS_lD_OF(FootnoteArea) } 
$FPDA:  REQ     Object-class      {OBJECT_CLASS  ID  OF ( FootnoteArea ) } 
}. 

REQ       Subordinates  { SUB_ID_0F( Specif icBlock)+} , 

PERM     Application-comments  {REQ''tconstraint-name  {"15"}, 

PERM  texternal-data  {ANY^VALUE}}} 


7.4.3.14 

BaaicBeader:  ANY -FRAME 

GENERIC : 

CASE 

$DAC  0F{ 

$PDA-FPDA: 

REQ 

Logical-source 

PERM 

Layout -path 

REQ 

Application-comments 

{ OB JECT_CLASS_iD_OF ( commonContent ) } } , 
{'270-degrees'  —  page  layouts  A,B,C  — 

I ' ISO-degrees '  —  page  layout  D  --}, 
{REQ  tconstraint-name  {"27"}, 

PERM  texternal-data  {ANY_VALUE}} , 
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SPECIFIC : 

CASE       $DAC  OF  { 

$FDA:    PERM  Object-class 

$FPDA:  REQ  Object-class 
}/ 

REQ  Subordinates 

PERM  Application-comments 


{OBJECT_CLASS_ID_OF(BasicHeader) } 
{OBJECT_CLASS_ID_OF(BasicHeader) } 

{SUB_ID_OF ( Specif icBlock)+} , 
{REQ  #constraint-name  {"27"}, 
PERM  #external-data  {ANY_VALUE) } } 


7.4.3.15    BasicPooter:  ANY -FRAME-FIXED  { 


GENERIC: 
CASE 

REQ 
PERM 


SPECIFIC: 
CASE 


REQ 


$DAC  0F{ 
$PDA-FPDA: 
Logical-source 
Layout-path 


REQ  Application-comments 


$DAC  OF  { 
$FDA:  PERM 
$FPDA:  REQ 
}, 

Subordinates 


Object-class 
Object-class 


PERM  Application-comments 


{OEJECT_CLASS_ID_OF(CommonContent) )  } , 
{ '270-degrees '  —  page  layouts  A,B,C 

I ' 180-degrees '  —  page  layout  D  — }, 
{REQ  #constraint-name  {"33"}, 

PERM  #external-data  {ANY__VALUE}  } , 


{OBJECT_CLASS_ID_OF(BasicFooter) } 
{OB JECT_CLASS_ID_OF ( BasicFooter ) } 

{SUB_ID__OF( Specif  icBlock)  +  }  , 
{REQ  #constraint-name  {"33"}, 
PERM  #external-data  {ANY_VALUE}}} 


7.4.3.16    CoaqmsiteBeader:  ANY-FRAME -FIXED  { 


GENERIC: 
CASE 

REQ 


REQ 

SPECIFIC! 
CASE 


REQ 


$DAC  OF  { 
$PDA-FPDA: 

Generator-for-subordinates 
}, 


PERM  Layout-path 


Application-comments 


$DAC  OF  { 

$FDA:     PERM  Object-class 
$FPDA:  REQ  Object-class 
}, 

Subordinates 


PERM  Application-comments 


{ $HeaderFooterGFS } 

{'270-degrees'  —  P^ge  layouts  A,B,C  — 
I  '  180-degrees '  —  page  layout  D  -•-}, 

{REQ  #constraint-name  {"5"}, 
PERM  #external-data  {ANY_VALUE}} 


{OBJECT_CLASS_ID_OF (CompositeHeader ) } 
{OB JECT_CLASS_ID_OF ( CompositeHeader ) } 

{ SUB_ID_OF ( SourcedContentFixed ) + , 
SUB_ID_OF ( ArrangedContentFixed ) + , 
SUB_ID_OF ( SourcedContentVariable ) + , 
SUB_ID_OF(ArrangedContentvariable ) +} , 

{REQ  #constraint-name  {"5"}, 
PERM  #external-data  {ANY_VALUE}}} 
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7.4.3.17    CoinpoaiteFooter :  ANY -FRAME -FIXED  { 


GENERIC: 
CASE 

REQ 

PERM 

REQ 

sPEciric  s 

CASE 


REQ 


$DAC  OF  { 
$PDA-FPDA! 

Generator-£or-8ubordinates 
}» 

Layout -path 
Application-comments 


$DAC  OF  { 

$FDA:    PERM  Object-class 
$FPDA:  REQ  Object-class 
}, 

Subordinates 


PERM  Application-comments 


{ $  HeaderFooterGFS } 

{ '270-degrees'  —  page  layouts  A^B^C  - 
j '180-degrees'  —  page  layout  D  --}, 

{REQ  #constraint-name  {"32"), 
PERM  #external-data  {ANY_VALUE}}, 


{OBJECT_CLASS_lD__OF  ( compositeFooter ) } 
{OBJECT_CLASS_iD_OF ( compositeFooter ) } 

{ SUB_ID_OF ( sourcedcontentFixed ) + , 
SUB_ID_OF ( Arr angedContentFixed ) + , 
SUB_ID_OF ( SourcedContentVariable ) +, 
SUB_ID_0F  ( Arrang€<dContentVju:iable ) +) , 

{REQ  #constraint-name  {"32"), 
PERM  #external-data  {ANY_VALUE))) 


7.4.3.18    SourcedContentVariable:  ANY-FRAME -VARIABLE  { 

GENERIC : 

CASE       $DAC  OF  { 
$PDA-FPDA: 


REQ 
REQ 


Logical-source 
Position 


{OB JECT_CLASS_iD_OF ( Commoncontent ) ) , 

{REQ  fvariadsle-position  { 

PERM  foffset  {ANY_VALUE), 
PERM  #separation  {ANY_VALUE), 
PERM  talignment  {ANY_VALUE), 
PERM  #f ill-order  { 'normal -order')) 


CASE  SUPERIOR  (CompositeHeader | CompositeFooter 

(Layout-path) )  OF  { 


{ '270-degree8') : 

REQ  Dimensions 


PERM  Layout -path 
{'180-degrees'): 

REQ  Dimensions 


{REQ  Ihorizontal-dimension 

{REQ  #fixed-dimension  {ANY__VALUE) 
|req  #maximum-size  {'applies')), 
REQ  #vertical-dimension 

{REQ  #£ixed-dimension  {ANY_VALUE) 
I REQ  #rule-b  {ANY_VALUE))), 

{'270-degrees') 

{REQ  #horizontal-dimen8ion 

{REQ  #fixed-dimension  {ANY^VALUE) 
I REQ  #rule-b  {ANY_VALUE)), 
REQ  #vertical-dimension 

{REQ  #fixed-dimension  {ANY_VALUE) 
jREQ  #maximum-size  {'applies'))). 
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REQ 

SPECIFIC: 
CASE 


REQ 
PERM 


REQ  Layout-path 

} 

} 

Application-comments 


$DAC  OF  { 

$FDA:    PERM  Object-clasa 
$FPDA:  REQ  Object-class 
}, 

Subordinates 
Application-comments 


{' ISO-degrees') 


{REQ  #conBtraint-name  {"19"}, 
PERM  #external-data  {ANY  VALUE}} 


{  OB  JECT_CLASS_ID_OF 

( SourcedContentVariable ) } 
{ OB JECT_CLASS_ID_OF 

( SourcedContentVariable ) } 

{SUB_ID_OF( Specif icBlock)+} , 
{REQ  #constraint-name  {"19"}, 
PERM  #external-data  {ANy_VALUE} } } 


7.4.3.19    ArremgedContentVariable:  ANY-FRAME -VARIABLE  { 

GENERIC: 

CASE       $DAC  OF  { 
$PDA-FPDA: 


REQ 


REQ  Position 


REQ 


Generator-for-subordinates 

{<construction-expr>: :=SEQ 
(OBJECT_CLASS__ID_OF(GenericBlock) ...);} 
{REQ  #variable -position  { 
PERM  #offset  {ANY_VALUE}, 
PERM  #separation  {ANY_VALUE}, 
PERM  #alignment  {ANY_VALUE}, 
PERM  #f ill-order  {'normal -order'}}. 
Dimensions  {REQ  thorizontal -dimension 

{REQ  #fixed-dimenaion  {ANY_VALUE}, 
REQ  ivertical-dimension 
{REQ  # fixed-dimension  {ANY_VALUE} } , 


REQ  Application-comments 


SPE  CIFIC: 
CASE      $DAC  OF  { 
$FDA: 


PERM 


$FPDA:  REQ 


Object-class 
Object-class 


REQ 
PERM 


Subordinates 
Application-comments 


{REQ  #constraint-name  {"17"}, 
PERM  #external-data  {ANY_VALUE}} , 


{  OB  JECT_CLASS_ID__OF 

(Arrangedcontentvariable) } 
{ OB JECT_CLASS_ID_OF 

(Arrangedcontentvariable) } 

{SUB_ID_OF(GenericBlock)+} , 
{REQ  #constraint-name  {"17"}, 
PERM  #external-data  {ANY_VALUE}}} 
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7.4.3.20    SourcedContentFixed:  ANY-FRAME -VARIABLE  { 


GENERIC : 
CASE 


$DAC  OF  { 
$PDA-FPDA: 


SPECIFIC: 
CASE 


REQ 
PERM 


REQ 
REQ 


Logical-source 
Position 


{ OB  JECT_CLASS_lD__OF  ( CommonContent ) } , 
{REQ  tfixed-position 

{REQ  #horizontal-po8ition{AllY_VALUE}, 
REQ  #vertical-position{ANY_VALUE}}> 
CASE  SUPERIOR  (CompositeHeader | Compositefooter 

(Layout-path))  OF  { 

{'270-degrees'}s 

REQ    Dimension       {REQ  thorizontal-dimension 

{REQ  # fixed-dimension  {ANY_yALUE>}, 
REQ  fvertical -dimension 
{REQ  # fixed-dimension  {ANY_VALUE} 
I  REQ  #rule-b  {ANY__VALUE})}, 
PERM  Layout-path    { '270-degrees ' } 
{ ' 180-degrees ' } : 

REQ    Dimension       {REQ  thorizontal-dimension 

{REQ  # fixed-dimension  {ANY_VALUE} 
I  REQ  #rule-b  {ANY__VALUE}}, 
REQ  #vertical-dimension 
{REQ  # fixed-dimension  {ANY_VALUE>}, 
.  REQ    Layout-path  {'180-degrees'} 


} 

REQ  Application-comments 


$DAC  OF  { 

$FDA:    PERM  Object-class 
$FPDA:  REQ  Object-class 
}, 

Subordinates 
Application-comments 


{REQ  #constraint-name  {"18"}, 
PERM  #external-data  {ANY_VALUE}} 


{ OB JECT_CLASS_ID_OF 

(SourcedContentFixed) } 
{  OB  JECT_CLASS__ID_OF 

(SourcedContentFixed) } 

{SUB_ID_0F ( Specif icBlock) +} , 
{REQ  #constraint-name  {"18"}, 
PERM  # external -data  {ANY_VALUE}}} 


7.4.3.21    ArrangedContentFixed:  ANY -FRAME -FIXED  { 

GENERIC : 

CASE       $DAC  0F{ 

$PDA-FPDA: 

REQ       Generator-for-subordinates  {SEQ(OBJECT_CLASS__ID_OF 

(GenericBlock) ...)}} r 
REQ       Application-comments  {REQ  #constraint-name  {"16"}, 

PERM  #external-data  {ANY_VALUE}} 
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SPECIFIC: 

CASE       $DAC  OF  { 

$FDA:    PERM  Object-class 

$FPDA:  REQ  Object-class 
>/ 

REQ  Subordinates 

PERM  Application-comments 


{ OB JECT_CLASS_ID_OF 

(ArrangedContentFixed) } 
{ OB JECT_CLASS_ID_OF 

(ArrangedContentFixed) } 

{SUB_ID_OF (GenericBlock ) +) , 
{REQ  #constraint-name  {"16"}, 
PERM  #external-data  {ANY^VALUE})} 


7.4.3.22 

GenericBlock:  block  { 

GENERIC : 

REQ 

Object-class-identifier 

{ANY_VALUE} 

REQ 

Object -type 

{ 'block'}. 

REQ 

Content-architecture-class 

{ $FC 1 $FPC 1 $FPR 1 $FPG} , 

PERM 

Resource 

{ANY_VALUE}, 

PERM 

Content -portions 

{CONTENT_ID__OF 

PERM  User-readeddle-comments 
PERM     User-visible -name 
PERM  Position 


PERM  Dimension 


REQ  Application-comments 


SPECIFIC: 
CASE 


CASE 


( character-content -portion ) + 
I  CONTENT  ID_OF 

( raster-graphic  s -content -portion ) 
I  CONTENT__ID_OF 

(geometric -graphics -content -port ion) } ; 
{ANY__STRING}  , 
{ANY~STRING} , 
{REQ  ifixed-position 

{REQ  #hori2ontal-position{ANY_VALUE}, 
REQ  #vertical-position{ANY__VALUE}}}, 
{REQ  #horizontal-dimension 

{REQ  « fixed-dimension  {ANY^VALUE}}, 
REQ  tvertical-dimension 

{REQ  #fixed-dimension  {ANY_value}}}, 
{REQ  Iconstraint-name  {"29"}, 
PERM  #external-data  {ANY__VALUE}} 


$DAC  OF  { 
$FDA:  PERM 
$FPDA:  REQ 
), 

Generic  Block  (object-class)  OF  {VOID: 


Object-class 
Object-class 


{OBJECT_CLASS_ID_OF( GenericBlock) } 
{0BJECT_CIASS__ID_0F( GenericBlock) } 


REQ  content-portions 


PERM  Application-comments 


{ CONTENT_ID_OF 

( char acter-content -portion )+ , 
CONTENT_ID__OF 

(raster-graphics-content -portion) , 
CONTENT_ID_OF 

( geometric-graphics-content -portion) } , 

}/ 

{REQ '#constraint -name  {"29"}, 
PERM  #external-data  {ANY_VALUE}}} 


SPECIFIC__AND_GENERIC : 

PERM  Presentation-style 


{  STYIiE_ID_OF  ( P-sty  le  1 ) 
STYLE_ID_OF ( P-Sty le2 ) 
STYLE_ID_0F(P-Style3) } , 
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7.4.3.23  Specif icBloek:  BLOCK  { 
SPECIFIC: 

PERM  Presentation-style 


REQ  Content-portions 


PERM  Application-comments 


{  STyLE__lD_OF  ( P-sty  le  1 ) 
STYLE_ID_OF ( P-Sty le2 ) 
STYLE~ID__OF  ( P-Style3 ) 

style_Id"of ( p-style4 ) > , 

{CONTENT__ID__OF 

( character-content -portion 
CONTENT_ID_OF 

(raster-graphics-content -portion) , 
CONTENT_ID_OF 

( geometric -graphics -content-portion) } , 

{REQ  #constraint-name  {"30"}, 
PERM  #external-data  {ANY__VALUE}}} 


7.5    Layout  style  constituent  conatrsuAts 
7.5.1    Macro  definitions 

DEFINE (LayoutobjectClasses ,  " 

OB JECT_CLASS_ID_©F ( Pageset ) 
OB  JECT__CLASS__ID_OF  ( Page ) 
OB  JECT_CIASS_ID__OF  ( Rec  toPage ) 
OB JECT_CLASS~ID_OF ( Ver soPage ) 
OBJECT_CLASS_ID_OF  ( Bas  icBody ) 
OBJECT__CLASS_lD_OF  ( VariableCompositeBody ) 
OB  JECT_CLASS_ID__OF  ( BasicFloat ) 
OB  JECT_CLASS_lD_OF  ( SnakingColumns ) 
OB  JECT__cliASS_lD_OF  ( SynchronizedColumns ) 
OB  JECT_CLASS_ID__OF  (  ColumnFixed ) 
OBJECT_CLASS_ID_OF  ( columnVariable ) 
-) 

DEFINE ( SameLayoutOb ject ,  " 

REQ  #logical-object{<object-id-expr>  ::=    PREC-OBJ(CURR-OBJ) ; 

I 'null'}, 
PERM  #layout-ob ject{ 'page ' } 
") 


7.5.2     FACTOR:  ANY -LAYOUT-STYLE  { 

REQ       Layout-style-identifier  {AliY_VALUE}, 

PERM     User-visible-name  {ANY~string}, 

PERM     User-readable-comments  {ANY__STR1NG} } 
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!.5.3    Layout  style  constituent  constraints 
,5.3.1    L-Stylels  ANY -LAYOUT-STYLE  { 

j 

—  this  style  is  used  for  the  constituent  Passage  only  — 

CASE  Doctunent -prof  lie  (Generic-layout-structure)  OF  { 
1  { ' complete-generator-set ' } : 

PERM  Layout-object-class  {OBJECT_CLASS__lD_OF(PageSet) } , 
PERM  New-layout-object  {OBJECT_CLASS_ID_OF(PageSet) } , 
PERM      Indivisibility  {$LayoutObjectClasses 

|anY__STRINg]  'page'  |  'null'} 

VOID : 

PERM      Indivisibility  {ANY_STRING | 'page ' | 'null ' } 

}} 

—  ANY_STRING  is  interpreted  as  representing  the  name  of  a  layout 
category  — 

.5.3.2    L-Style2i  ANY -LAYOUT -STYLE  { 

—  this  style  is  used  for  the  constituents 
BodyText,  and  Number  — 

CASE  Document -prof  lie  (Generic-layout-structure)  OF  { 
{ 'complete -generator-set ' } : 
PERM  Indivisibility 


PERM  New-layout -object 

VOID: 

PERM  Indivisibility 

PERM  New-layout-object 

PERM  Layout-category 

PERM  Same-layout -object 

PERM  Concatenation 

PERM  Offset 

PERM  Separation 

PERM  Block-alignment 
PERM  Synchronization 


{ $LayoutOb jectclasses , 

I ANY_STRING | 'page ' \ ' null ' ) , 
{$LayoutOb jectclasses 
|any_string| 'page' | 'null'} 

{ANY_STRING  'page'  'null'}, 
{Airy_STRING  'page'  'null'} 
} 

{ANY_STRING}, 

{ $SameLayoutOb ject } , 

{ANY_VALUE}, 

{ANY_VALUE>, 

{PERM  # leading-edge {ANY_INTEGER}, 
PERM  #trailing-edge  {ANY_INTEGER}  } , 
{ANY_VALUE}, 
{ANY_VALUE}} 


7.5.3.3    L-Style3:  ANY -LAYOUT-STYLE  { 

I  —  this  style  is  used  for  the  constituents 

CommonText  and  PageNumber  — 


PERM  Concatenation 

PERM  Offset 

PERM  Block-alignment 

PERM  Sepauration 


{ANY__VALUE}, 
{ANY~VALUE}, 
{ANY_VALUE}, 

{PERM  #leading-edge{ANY_INTEGER}, 
PERM  #trailing-edge { ANY_INTEGER} } } 
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7.5.3.4    L-Style4s  ANY -LAYOUT -STYLE  { 

this  style  is.  used  for  the  constituents  NxunberedSegment 
and  Paragraph  — 


CASE  Docuinent-profile(Generic-lay©ut"Struetur©)  OF  { 
{ ' complete -generator-set ' ) s 
PERM  Indivisibility 


VOID! 


PERM  Layout -object-class 
PERM  New-layout-object 


PERM  Indivisibility 
PERM      New- layout -object 


PERM 


SMie-layout -object 
Synchronization 


{ $LayoutOb jectclasses 

I ANY_STRING | ' page ' I ' null ' ) , 
<OBJECT_CLASS_lD_OF ( PageSet ) } , 
{ $LayoutOb jectclasses 
|any_string| 'page' | 'null'} 

{ANY_STRING  'page'  'null'}, 
{MJY_STRING  'page'  'null'} 
} 

{^SameLayoutObject} , 
{ANY_VALUE}} 


—  ANY__STRING  is  interprets? 
category 


13  representing  the  name  of  a  layout 


7.5,3.5    L-Style5:  ANY -LAYOUT-STYLE  { 

this  style  is  used  for  the  constituents 
Body Raster  and  BodyGeometric  — 

CASE  Document-profile( Generic-layout-structure)  OF  { 
{ 'complete -generator-set ' } s 

PERM     New-layout-object        {$LayoutOb jectclasses, 

|any_STRINg| 'page' I 'null'} 

VOID: 

PERM      New-layout-object        {ANY_STRINGj 'page' | 'null'} 

} 

—  ANY_STRING  is  interpreted  as  representing  the  name  of  a  layout 
category  =•=• 


PEBM  Layout-category 

PERM  Offset 

PERM  Same-layout -object 

PERM  Separation 

PERM  Block-alignment 

PERM  Synchronization 


{ANY_STRING}  , 
{ANY_VALUE}, 
{ $sameLayoutob ject } , 
{PERM  #leading-edge{ANY_INTEGER}, 
PERM  #trailing-edge { ANY_INTEGER} } , 
{ANY_VALUE}, 
{ANY_VALUE}} 
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7.5.3.6    L-Style6:  ANY -LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituent  FootnoteText  — 


REQ       Layout -category 
PERM  Concatenation 
PERM  Indivisibility 


PERM  Offset 

PERM  Block-alignment 

PERM  sepeoration 


{"Footnote"} , 
{ANY_VALUE}, 

{ OB JECT_CLASS_lD_OF  ( FootnoteArea ) 
" 'PAGE' 
'NULL'}! 
{ANY_VALUE}, 
{ANY_VALUE}, 

{PERM  #leading-edge{ANY_INTEGER}, 
PERM  #trailing-edge {ANY_INTEGER}  } } 


7.5.3.7    L-Style7:  ANY -LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituent  Footnote  only  — 
,  PERM     Same-layout -object  {§SameLayoutObjeot} } 


7.5.3.8  L-Style8t 


{ 


~  this  style  is  used  for  the  constituents 
CoiranonRaster  and  CommonGeometric  — 


PERM  Offset 

PERM  Block-alignment 

PERM  Separation 


{ANY_VALUE| ^ 
{ANY_VALUE} , 

{PERM  #leading-edge{ANY_INTEGER} , 
PERM  #trailing-edge{ANY_INTEGER}}} 


7.5.3.9     L-Style9:  ANY -LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituent  FootnoteNumber  — 

REQ       Layout-category  {"Footnote"}, 
PERM      Offset  {ANY_VALUE}, 
PERM     Block-alignment  {ANY_VALUE}, 

PERM     Separation  {PERM  #leading-edge{ANY_INTEGER} , 

PERM  #tr ailing-edge { ANY_INTEGER} } } 

17.5.3.10    L-StylelOj  ANY -LAYOUT-STYLE  { 

—  this  style  is  used  for  the  constituents 
FootnoteReference  only  — 

CASE  Document -profile (Generic-layout-structure)  OF  { 
{ 'complete-generator-set' } : 

PERM      indivisibility  {$LayoutObjectClasses, 

|ANY_STRINGj 'page' | 'null'} 

VOID: 

PERM      Indivisibility  {ANY_string| 'page' | 'null'} 

} 
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PERM  Layout -category  {ANY_STRING) , 

PERM  Same-layout -object  {$SasieLayoutObject} , 

PERM  Concatenation  {ANY_VALUE}, 

PERM  offset  {ANY_VM.UE}, 

PERM  Separation  {PERM  #leading-edge{ANT_INTEGER}, 

PERM  #trailing-edge  { ANY__INTEGER}  } , 

PERM  Block-alignment  {ANY_VALUE)  ~ 

7.5.3.11     L-Stylell:  ANY_LAYOUT_STYLE { 

—  this  style  is  used  for  the  constituent  Footnotebody 
PERM     Same-layout -object  {$SameLayoutObject}, 
PERM     Indivisibility  {OBJECT_CLASS_ID_OF  (FootnoteArea) 

' 'PAGE'  ~ 
'NULL'}; 

7.fi    Presentation  style  constituent  constraints 

7.6.1  Macro  definitions 

No  macro  definitions  are  applic2J3le  to  this  clause. 

7.6.2  Factor  constraints 

7.6.2.1    FACTOR:  ANY-PRESENTATION-STYLE  { 

REQ  Presentation-style-identifier  {ANY_VALUE}, 

PERM  User-visible-name  {ANY^STRING} , 

PERM  Border  {ANY^VALUE}, 

PERM  User-readable-comments  {ANY^STRING}} 


7.6.3    Presentation  style  constituent  constraints 

7.6.3.1     P-Stylel:  ANY-PRESENTATION-STYLE  { 

—  this  style  is  used  for  the  constituents  BodyText,  Number, 

FootnoteNumber,  FootnoteReference,  FootnoteText,  GenericBlock  and 
SpecificBlock  — 


PERM    Presentation  attributes  { 
PERM  #character-attributes  { 
PERM  ialignment 
PERM  fcharacter-spacing 
PERM  #character-fonts 
PERM  #character-orientation 

PERM  #character-path 

PERM  tcode-extension-announcers 

PERM  #first-line-offset 

PERM  #graphic -character-sets 


{ANY__VALUE} , 
{ANY_VALUE}, 
{ANY__VALUE}, 
{ '0-degrees' 

I  '9 0-degrees'}, 
{ANY_VALUE}, 
'{$CDEXTAN}, 
{ANY__VALUE}, 
{$PERMIT-GRCHAR} , 
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PERM  tgraphic -character 
PERM  # indentation 
PERM  titemisation 
PERM  #kerning-o££set 
PERM  tline-progression 
PERM  tline-spacing 
PERM  tline-layout -table 
PERM  forphan-size 
PERM  tproportional-line-spacing 
PERM  #widow-size 


aubrepertoire 
{ANY 
{ANY^ 

{any] 
{any" 
{any" 
{any] 
{any] 
{any] 
{any' 


{any_value}, 
valueJ, 

VALUE}, 
VALUE), 
]VALUE}, 
]VALUE>, 
]VALUE>, 
]VALUE>, 
]VALUE), 
VALUE}}} 


7.6.3.2    P-Style2:  ANY-PRESENTATION-STYLE  { 

—  this  style  is  used  for  the  constituents  BodyGeometric ,  CommonGeometric, 
Generic  Block  and  Specific  Block  — 


PERM    Presentation  attributes  { 

PERM  #geometric -graphics -attributes  { 


PERM  tpicture -dimensions 
PERM  tpicture-orientation 
PERM  #text-rendition 


{ANY__VALUE},  , 
{ANY_VALUE}, 

{PERM  #font8-list{ANY_VALUE}, 
PERM  tcharacter-set-list 

{ANY_VALUE}} 


7.6.3.4    P-Style3:  ANY-PRESENTATION-STYLE  { 

—  this  style  is  used  for  the  constituents  BodyRaster,  commonRaster,  Generic 
Block  and  Specific  Block  — 


PERM    Presentation  attributes  { 
PERM  fraster-graphics-attributes 
PERM  # image -dimensions 
PERM  iclipping 
PERM  #pel-spacing 
PERM  #spacing-ratio 


{ANY_VALUE} , 
{ANY~VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}}} 


7.6.3.5    P-Style4:  ANY-PRESENTATION-STYLE  { 

—  this  style  is  used  for  the  constituents  CommonText,  PageNumber  and 
SpecificBlock  — 

PERM    Presentation  attributes  { 
PERM  #character-attributes  { 

PERM  falignment  {ANY_VALUE}, 
PERM  #character-spacing  {ANY_VALUE}, 
PERM  #character-fonta  {ANY_VALUE}, 
PERM  #character-orientation  '  {'0-degrees' 

j '9 0-degrees'}, 
PERM  #character-path  {'0-degrees' 

'180-degrees' 
'27 0-degrees'}, 
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PERM  icode-extension-announcers  {$CDEXTAN}, 

PERM  #first-line-offset  {ANY_VALUE}, 

PERM  tgraphic -character-sets  {$PERMIT-GRCHAR} , 

PERM  tgraphic-character-subrepertoire  {ANY_VALUE}, 

PERM  tgraphic-rendition  {$GRAPHICRENDITIONS} , 

PERM  #indentation  {ANY_VALUE}, 

PERM  #iteinisation  {ANY_value}, 

PERM  tkerning-offset  {ANY_VALUE}, 

PERM  tline-progresaion  {ANY_VALUE}, 

PERM  #line-8pacing  {ANY_VALUE}, 

PERM  #line-layout -table  {ANY_VALUE}, 

PERM  fproportional-line-spacing  {ANY_VALUE} } } 


7.7    Content  portion  constituent  constraints 
7.7.1    Macro  definitions 

No  macro  definitions  are  applicable  to  this  clause, 


7.7.2    Factor  constraints 

7.7.2.1     FACTOR:  ANY -CONTENT  { 

CASE  $DAC  OF  { 
$FDA: 

REQ  Content-identifier-layout  {ANY_VALUE} 

$PDA: 

REQ  Content-identifier-logical  {ANY_VALUE} 

—  This  attribute  is  specified,  if  the  content  portion  is 
associated  with  a  basic  logical  object  or  a  basic  logical 
object  class.  — 

jREQ  Content-identifier-layout  {ANY_VALUE} 

—  This  attribute  is  specified,  if  the  content  portion  is 
associated  with  a  basic  layout  object  class.  — 

$FPDA: 

REQ  Content-identifier-layout  {ANY_VALUE}, 
REQ  Content-identifier-logical  {ANY_VALUE} 

—  Both  attributes  are  specified,  if  the  content  portion 
is  associated  with  a  basic  logical  object  and  a  basic 
layout  object.  — 

I REQ  Content-identifier-layout  {ANY_VALUE} 

—  This  attribute  is  specified,  if  the  content  portion  is 
associated  with  a  basic  layout  object  class.  — 

I REQ  Content-identifier-logical  {ANY_VALUE} 

—  This  attribute  is  specified,  if  the  content  portion  is 
associated  with  a  basic  logical  object  class.  — 
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.7.3    Content  portion  constraints 


.7.3.1    Character-content-portion:  ANY -CONTENT  { 


PERM 
PERM 
PERM 


Type -of -coding 

Alternative-representation 

Content-information 


{ASN.1{2  8  3  6  0}}, 
{ANY^STRING} , 


{CHARACTER  {#STAB 


{ANY_VALUE} 


#SHS  {0,1,2,3,4} 

#SGR  {§GRAPHICRENDITIONS} 

#SVS  {ANY_VALUE} 

#SLS  {ANY_VALUE} 

#  SCS       {  ANY_VAIiUE  } 

#SRS  {ANY_VALUE} 

#JFY  {0} 

#CR 

#LF 

#VPB 

#VPR 

#PLD 

#PLU 

#SP 

#SUB 

#BPH 

#NBH 

#SOS 

#ST 

#LSO 

#LS1R 

#LS2R 

#LS3R 

#SS2 

#SS3 

#ESC { $DEG-CORE-G0 } 
#ESC { $DEG-6  4  6 -GO } 
#ESC { $DEG-ANY-G1 } 
#ESC{$DEG-ANY-G2} 
#ESC { $DEG-ANY-G3 } 
#ESC { $DEG-EMPTY-G1 } 
}...}} 
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7.7.3.2  Raater-graphics-content-portion:  ANY-CONTENT  { 


PERM     Nusiber-o£-lines  {>0}, 
REQ       Number-of-pels-per-line  {>bO}, 
PERM      Type-o£-coding  {ASN.1{2  8  3  7  0)  — 

|asn.1{2  8  3  7  1>  — 

|asn.1{2  8  3  7  2}— 

|asn.1{2  8  3  7  3}— 
PERM     Compression  {ANY_VALUE} , 

PERM     Alternative-representation       {ANY^STRZNG} , 
PERM     Content-information  {RASTER} } 


T.6  encoding  — 
T.4  one-dimensional 

encoding  — 
T.4  two  dimensional 

encoding  — 
bitmap  encoding  — }, 


7.7.3.3    Gecmetric-graphics-content-portion:  ANY-CONTENT  { 

PERM     Type-of -coding  {ASN.1{2  8  3  8  0}}, 

PERM     Alternative-representation       {ANY__STRING} ,  . 
PERM     Content-information  {GEOMETRIC}} 

8       Interchange  format 

For  conformance  to  this  profile,  the  interchange  format  class  A  shall  be  used 
when  applying  ODIF,  and  the  interchange  format  SDIF  shall  be  used  when  applying  \ 
ODL  in  conjunction  with  SDIF. 


8.1    Interchange  format  class  A 
8.1.1    Interchange  format 

The  value  of  the  document  profile  attribute  "Interchange  format"  for  this 
interchange  format  is  "if-a".    This  form  of  ODIF  is  defined  in  CCITT 
Recommendation  T. 415 | ISO  8613-5. 


8.1.2    DAP  identifier 

The  value  for  the  document  profile  attribute  "Document  application  profile"  for 
this  interchange  format  is  represented  by  the  following  object  identifier. 

ASN.l  {2  8  4  0  26  0} 
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8.1.3    Encoding  of  application  ccnmenta 

The  encoding  of  the  attribute  "application  conunenta"  is  defined  in  this  encoding 
as  an  octet  string  as  specified  in  CCITT  Recommendation  T. 415 | ISO  8613-5.  This 
document  application  profile  requires  that  the  encoding  within  that  octet  string 
be  in  accordance  with  the  ASN.l  syntsuc  specified  in  the  following  module 
definition : 

FOD-DAPSpecif ication 
DEFINITIONS :  «BEGIN 
EXPORTS  Appl-Comm-Encoding; 

Appl-Comm-Encoding : : =         SEQUENCE { 
constraint -name  [0]  IMPLICIT  Printedalestring  OPTIONAL, 

external-data  [1]  IMPLICIT  octet  string  optional  ) 

END 


8.1.4    Data  lengths  , 

The  mcucimvun  length  of  data  values  of  the  type  OCTET  STRING,  as  defined  in  ISO 

8824,  in  data  streams  which  may  be  encoded  in  accordance  with  this  DAP  is  32767 

octets.    If  it  is  required  to  encode  an  octet  string  of  greater  length  than 
this,  constructed  type  encoding  shall  be  used.    That  is,  data  values  greater 

than  32767  in  length  shall  be  split  into  a  sequence  of  strings  shorter  than 
32767,  each  of  which  is  encoded  using  a  primitive  type. 

8.2    Interchange  format  SDIF 

8.2.1  Interchange  format 

The  document  profile  attribute  "Interchange  format"  does  not  apply  for  this 
interchange  format.    This  form  of  ODIF  is  defined  in  Annex  E  of  CCITT 
Recommendation  T.415|lSO  8613-5.    CCITT  Recommendation  T.415|lSO  8613-6,  -7  and 
-8  contain  additional  specifications  for  interchange  format. 

8.2.2  DAP  identifier 

The  value  for  the  attribute  "Document  application  profile"  for  this  interchange 
format  is  represented  by  the  following  object  identifier. 

ASN.l  {1  0  11181  0  26  0} 

NOTE  -  There  is  no  requirement  to  include  a  part  number  arc  within  the 
object  identifier  for  the  DAP. 
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8.2.3    Encoding  of  application  camments 

The  encoding  of  the  attribute  "Application  comments "  is  defined  in  data  stream 
conforming  to  this  profile  with  this  encoding  with  the  following  DTD  definition: 

<t — Public  document  type  definition.    Typical  invocation: 
<IDOCTYPE  fodapc  PUBLIC  "ISO/IEC  11181-1   :  1992//DTD 

Application  Comments //EN"  [*•]> 

— > 

<1 ELEMENT  fodapc      -0  (externl7)> 
<1ATTLIST  fodapc      consname  CDATA  #IMFLIED> 
<1 ELEMENT  externl     -0  (#PCDATA)> 
<IATTLIST  externl     loc       ENTITY  #CONREF> 

For  example,  a  typical  SUBDOC  for  representing  the  "application  comments"  of  a 
Paragraph  then  would  look  like: 

<1D0CTYPE  fodapc  PUBLIC  "ISO/IEC  11181-1  :  1992//DTD  Application  Comments //EN">  s 
<fodapc  consname=6> 

If  the  optionality  of  the  attribute  "fodapc"  is  specified  in  an  earlier  portion 
of  the  DTD,  the  invocation  may  be  minimised  further  because  the  tag  is  not 
needed  when  "application  comments"  are  not  included  as  is  the  case  here. 

Thecontent  of  external  data  appearing  inline  is  rfestricted  to  parsable  data. 
Referenced  external  data  need  not  be  parsable. 
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ANNEX  A 
Anendments  and  corrigenda 

(This  annex  forms  an  integral  part  of  this  specification.) 
A.  1  Anendments 

A.  1.1    Amendments  to  the  base  standard 

The  amendments  applicable  to  this  ISP  includes  the  [CCITT  Recommendation 
T.41l|lSO  8613-1]  -  Amendment  1:  1990.      This  amendment  includes  text  to  be 
included  in  [CCITT  Recommendation  T.41l|lS0  8613-1]  as  the  following  annexes: 

Annex  E:  Use  of  ISO/IEC  10021  (MOTIS)  to  interchange  documents 
conforming  to  CCITT  Recommendation  T.415|lSO  8613; 

Annex  F:  Document  Application  Profile  proforma  and  notation; 

Annex  6:  confoinnance  testing  methodology; 

-  Annex  H:  Recording  of  documents  conforming  to  [CCITT  T.410  series 
Recommendations  I ISO  8613]  on  flexible  disk  cartridges  conforming  to 
ISO  9293. 

In  addition,  this  amendment  addresses  the  inclusion  of  the  CCITT  T.410  series 
Recommendations  I ISO  8613  Technical  Corregenda  1. 

This  ISP  does  not  include  the  following  features  of  the  amendment: 

-  Addendum  on  security; 
Addendum  on  styles; 

Addendum  on  alternative  representation. 

Addendum  on  colour; 

Addendum  on  tiled  raster  graphics 

A.  1.2    Proposed  changes  to  standards  due  to  defects 

Proposed  Technical  Corrigendum  No.  44  to  [CCITT  T.410  series  Recommendations | 
ISO  8613]  dated  15  December  1991  assumed  to  be  ratified  by  ISO. 

A.2  Corrigenda 

A. 2.1    Corrigenda  to  the  ISP 

There  is  no  corrigendum  specific  to  this  ISP. 
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ANNEX  B 
Reconmendationa 


(This  annex  does  not  form  an  integral  part  of  thia  Specification.) 


B.l    Transfer  methods  for  ODA 


B.1.1    Conveyance  of  ODA  over  CCITT  Z. 400-1984 

This  recommendation  describes  how  ODA  body  parts  are  to  be  encoded  for 
transmission  over  a  CCITT  X. 400-1984  service. 

An  ODA  body  part  is  encoded  as  odaBodyPart  in  the  definition  given  below: 

OdaBodyPart         SEQUENCE  {  odziBodyPartParaneter s ,  OdaData  > 
OdaBodyPartParameters  : : «  SET  { 

document-application-profile 

[0]   IMPLICIT  OBJECT  IDENTIFER, 
document-architecture-class 
[1]   IMPLICIT  INTEGER  { 
-     .  formatted  ( 0 ) , 

processable  (1), 
formatted-processable  (2)  } 
OdaData  ::bsequence  OF  Interchange-Data-Element 


NOTE  -  It  is  recommended  to  transfer  an  ODA  document  as  a  single  body  part 

with  tag  12: 

Oda  [12]   IMPLICIT  OCTETSTRING 

The  content  of  the  octet  string  is  encoded  as  OdaBodyPart,  defined  above. 
However,  this  is  out  of  the  scope  of  this  profile. 


B.l. 2    Conveyance  of  <»>A  over  FTAN 

This  recommendation  describes  the  FTAM  Document  Type  to  be  used  for  minimal 
storage  and  transfer  capabilities  of  ODA  data  streams.    It  is  recognized  that 
enhanced  capabilities  may  at  some  point  be  added. 

When  using  FTAM  to  transfer  an  ODA  file,  the  FTAM-3,  "ISO  FTAM  Unstructured 
Binary",  document  type  shall  be  specified. 


132 


rOD26  Part:  1  -  Document  Application  Profile  July  1992 

Bovever,  since  files  that  do  not  contain  ODA  data  streams  can  have  the  same 
document  type,  it  is  left  up  to  the  user  of  application  programs  that  remotely 
access  files  using  FTAM  to  know  that  a  given  file  contains  an  ODA  data  stream. 

B.1.3    Conveyance  of  ODA  over  DTAM 

This  recommendation  provides  for  information  concerning  the  interchange  of  ODA 
i  based  documents  with  DTAM  protocols . 

DTAM  (Document  Transfer  and  Manipulation)  is  defined  in  the  T.430-Series  of 
recommendations  and  is,  like  ODA,  an  integral  part  of  the  T.400-Series  of  CCITT 
Recommendations  named  Open  Document  Architecture,  Transfer  and  Manipulation. 

The  T.520-Series  of  recommendations  contain  Communication  Application  Profiles 
(CAP).    Recommendation  T.522  describes  the  Communication  Application  Profile  BTl 
for  document  bulk  transfer.    Recommendation  T.522  is  applicadsle  for  the  Office 
Document  Format  Profile  (FOD)  published  in  this  iSP. 

NOTE  -  The  use  of  BTl  within  the  end-to-end  oriented  Telematic  Services 
Telefax  4  and  Teletex  is  described  in  Recommendation  T.561,  subclause  7.1 
and  Recommendation  T.562,  subclause  7.1. 


B.1.4    Conveyance  of  ODA  over  flexible  disks 

The  recommended  method  for  interchanging  ODA  documents  between  systems  by  the 
exchange  of  magnetically  recorded  Flexible  Disk  Ceirtridges  is  by  the  use  of  an 
annex  to  ISO  8613-1  (to  be  published),   "Recording  of  Documents  Conforming  to 
ISO  8613  on  Flexible  Cartridges  Conforming  to  ISO  9293".    This  annex  provides 
for  recording  each  ODA  document  as  a  separate  file  as  defined  by  ISO  9293, 
"Volume  and  File  Structure  of  Flexible  Disk  Cartridges  for  Information 
Interchange" . 

NOTE  -  Documents  encoded  in  ODL  may  be  stored  such  that  each  SGML  ENTITY  is 
recorded  in  a  separate  file  or  in  the  case  of  an  SDIF  encoding,  the  file 
may  be  stored  in  a  single  file. 

B.2    Font  reference 

The  recommended  method  for  specifying  a  font  reference  is  to  be  based  on  ISO 
9541. 
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Font  sizes  from  6  to  72  points  (100  to  1200  BMU)  are  intended  to  be  supported  by 
implementation  conforming  to  this  recommendation.    All  other  values  of  font 
sizes  may  additionally  be  supported,  but  implementations  may  also  support  using 
some  form  of  "fallback*;. 

The  minimum  font  properties  and  values  from  ISO  9541  that  are  to  be  specified  in 
a  Font -Attribute -set  be  those  specified  by  the  following  document  application 
profile  notation. 

Font-Attribute-set{ 


PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 


PERM 
PERM 


PERM 


PERM 


PERM 
PERM 


Fontname 

Standard-Version 
Design-Source 
Font -Family-Name 
Posture 
Weight 

Proportionate -Width 
Glyph-Complement  { 
PEim  #Included-Glyph-Collections 

{ANy_VALUE), 
PERM  #Excluded-Glyph-Collections 

{ANY_VALUE}, 

PERM  #Included-Glyphs 
PERM  lExcluded-Glyphs 


{ANY_VALUE}, 
{ANY_VALUE), 
{ANY^VALUE}, 
{ANY_VAHJE), 

{'upright'  |  'italic-forward'}, 
{'light'  I   'medium'  j  'bold'}, 
{ANY_VALUE}, 


{ANY_VALUE}, 
{ANY_VALUE} 


Design-Size 
Min-Size 
PERM  #Numerator 
PERM  #Denominator 

Max-Size 
PERM  #Numerator 
PERM  iDenominator 


{ 


>/ 

{ 


{ANY_VALUE}, 

{100  ..  1200}, 
{1} 


{100 
{1} 


1200}, 


—  BMU  Units 


equivalent 


Design-Group 
PERM  IClass 
PERM  tsubclass 
PERM  tspecif ic-Group 


{ 


to  range  of  6.. 72  point  sizes  — 

{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 

{ANY_VALUE}, 


Structure 
Writing-Modes  { 
MUL 

PERM  #Writing-Mode-Name 
PERM  iNominal-Escapement-Direction 

{ANY__VALUE}, 

PERM  lEscapement -Class 
PERM  #Average-E3capement-X 
PERM  #Average-Escapement-Y 

} 

} 


{ 

{ANY_VALUE}, 


{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY_VALUE} 
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B.3    ISO  8632  (CGM)  constraints  for  this  DAP 

It  is  recosnnended  that  geometric  graphics  content  information  contain  only  those 
elements  listed  in  this  portion  of  the  document,  in  addition  to  the  constraints 
imposed  by  CCITT  Recommendation  T.415|lSO  8613-8.    it  is  believed  that  this 
subset  of  the  CGM  is  sufficiently  implemented  to  enable  interworking  of 
geometric  graphics  for  application  conforming  to  this  document  application 
profile . 

j  where  an  element  has  parameters,  recommended  constraints  on  the  values  are 
I  given.    The       "  symbol  indicates  that  there  is  no  recommended  constraint. 

I  Requirements  in  ISO  8632  and  CCITT  Recommendation  T.415|lSO  8613-8  concerning 
I  mandatory  elements,  peurameters  shall  be  fulfilled. 

B.3.1    Dellneter  elenents 
No-op 


An  arbitrary  sequence  of  n  octets.  Where 
n=0,  1,....,  32  767.     The  sequence  of 
zero  or  more  octets  is  for  padding  purposes. 


Begin  Metafile  support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets. 

End  Metafile 


Begin  Picture  Support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets. 

Begin  Picture  Body 
End  Picture 


B.3. 2    Metafile  descriptor  elements 


Metafile  Version  1 

Metafile  Description  support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets.    The  METAFILE 
DESCRIPTION  String  parameter  will  be  used  to 
include  the  sub-string  "ISO  FOD26"  to  Isibel 
the  content  information  as  conforming  to 
this  profile.     In  addition,  generators  of 
content  are  encouraged  to  append  a  sxib- 
string  that  identifies  the  company  and 
product  that  produced  the  CGM. 
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VDC  Type  Integer 

Integer  Precision  16 

Real  Precision  •  (0,9,23),  (1,16,16) 

Index  Precision  16 

Colour  Precision  8,  16 

Colour  Index  Precision  8,  16 

Maximum  Colour  Index  0  . .  63 

Colour  Value  Extent 

Metafile  Element  List  — 

Metafile  Defaults  Replacement  — 

Font  List  All  fonts  referenced  in  the  metafile  shall 

be  defined.    Font  referencing  in  FONT  LISTS 
using  ISO  9541  names  is  preferred,  but  font 
names  may  be  specified  using  proprietary 
font  names. 

Character  Set  list  All  cheoracter  sets  referenced  in  the 

metafile  shall  be  defined  in  CHARACTER  SET 
LIST.    Permissible  character  sets  are  the 
same  as  for  character  content  aurchitecture . 

CHaracter  Coding  Announcer  — 


B.3.3    Picture  descriptor  elements 


Scaling  Mode  The  Scale  Factor  parameter  of  SCALING  MODE 

element  is  always  a  32-bit  floating  point 
value,  even  when  the  REAL  PRECISION  has  | 
selected  fixed  point  for  other  real  numbers.! 
It  is  not  apparent  in  ISO  8632  what  the 
precision  of  this  floating  point  value  is 
when  fixed  point  has  been  selected.  Its 
precision  shall  be  (0,9,23). 

Colour  Selection  Mode  Indexed  | 

Line  Width  Specification  Mode  Scaled 

Marker  Size  Specification 

Mode  Scaled 

Edge  Width  Specification  Mode  Scaled 

VDC  Extent 

Background  Colour 


B.3.4    Control  elements 

VDC  Integer  Precision 
VDC  Real  Precision 
Auxiliary  Colour 
Transparency 
Clip  Rectangle 
Clip  Indicator 


16 

(0,9,23),  (1,16,16) 
Transparent 

M 
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B.3.5    Graphical  priaitive  elaawnts 

Polyline  support  for  point  lists  with  up  to  255 

vertices . 

Disjoint  Polyline  support  for  point  lists  with  up  to  255 

vertices . 

Polynarker  support  for  point  lists  with  up  to  255 

vertices . 

Text  Support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets.  Format  effector 
control  characters  eure  disallowed  in  the 
string  parameter. 

Restricted  Text  support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767,  octets.  Format  effector 
control  characters  are  disallowed  in  the 
string  parameter. 

Append  Text  support  will  be  provided  for  strings  with  a 

length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets.  Format  effector 
control  characters  are  disallowed  in  the 
string  peurameter. 

Polygon  support  for  point  lists  with  up  to  255 

vertices . 

Polygon  Set  support  for  point  lists  with  up  to  255 

vertices . 

Cell  Array 
Rectangle 

Circle 

circular  Arc  3  Point 
Circular  Arc  3  Point  close 
Circular  Arc  Centre 
Circular  Arc  Centre  close 
Ellipse 

Elliptical  Arc 
Elliptical  Arc  close 
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B.3.6    Attribute  elenenta 


Line  Bundle  Index 
Line  Type 
Line  Width 
Line  colour 
Marker  Bundle  Index 
Marker  Type 
Marker  Size 
Marker  Colour 
Text  Bundle  Index 
Text  Font  Index 


Text  Precision 
Character  Expansion  Factor 
Character  Spacing 
Text  Colour 
Character  Height 
Character  orientation 
Text  Alignment 
Character  Set  Index 


1 

1-5 


1 

1-5 


All  fonts  referenced  {indexed  by  TEXT  font 

INDEX)  in  the  metafile  shall  be  defined  in 

FONT  LIST  either  in  presentation  parameters 

of  ISO  8613  or  in  ISO  8632. 

0  (string) 

1.0 

0.0 


Alternate  character  Set  Index 


Fill  Bundle  Index 
Interior  Style 
Fill  colour 
Batch  Index 
Pattern  Index 
Edge  Bundle  Index 
Edge  Type 
Edge  Width 
Edge  Colour 
Edge  Visibility 
Fill  Reference  Point 


All  character  sets  referenced  in  the 
metafile  (indexed  by  CHARACTER  SET  INDEX) 
shall  be  defined  in  CHARACTER  SET  LIST.  The 
only  character  sets  which  may  be  designated 
in  GO  are  ISO  646  IRV  or  versions  of  ISO 
646.    Other  character  sets  shall  be 
designated  in  Gl,  G2  or  G3. 
All  character  sets  referenced  in  the 
metafile  (indexed  by  ALTERNATE  CHARACTER  SET 
INDEX)  ehall  be  defined  in  CHARACTER  SET 
LIST. 

1 


1 
1 
1 

1.0 


0  (off) 
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Pattern  Table 


Pattern  size 

Colour  Table  Specification 


Aspect  Source  Flags 
B.3.7    External  elements 
Message 


Application  Data 


The  PATTERN  TABLE  element  has  an  unspecified 
effect  when  it  appears  in  a  picture 
subsequent  to  any  graphical  primitives .  The 
PATTERN  TABLE  element  shall  appear  prior  to 
any  graphical  primitive  element  to  assure 
that  interpreting  systems  without  dynaonic 
pattern  update  can  render  the  intended 
effect.     The  minimum  support  for  the  length 
of  the  Colour  Array  parameter  for  the 
PATTERN  TABLE  element  is  2  048.     This  will 
support  8  patterns  of  16x16,  2  patterns  of 
32x32  or  1  pattern  of  32x64.    All  indexes 
whch  are  used  in  the  metafile  shall  be 
defined. 

The  COLOUR  TABLE  element  has  an  unspecified 
effect  when  it  appears  in  a  picture 
subsequent  to  any  graphical  primitives .  The 
COLOUR  TABLE  element  shall  appear  prior  to 
any  graphical  primitive  elements  to  assure 
that  interpreting  systems  without  dynamic 
colour  update  can  render  the  intended 
effect.     The  minimum  support  for  the  length 
of  the  Colour  List  parameter  in  the  COLOUR 
TABLE  element  is  63.      This  will  support  a 
64  (0..63)  entry  colour  table.     All  indexes 
which  are  used  in  the  metafile  shall  be 
defined. 
Individuals 


The  presentation  of  message  string  may  not 
be  appropriate  for  all  applications.  No 
requirement  for  the  formatted  presentation 
of  the  message  string  has  been  placed  on  the 
Interpreter.     Only  the  No  Action  flag  needs 
to  be  supported.     Support  for  string  lengths 
up  to  254. 

Support  will  be  provided  for  strings  with  a 
length  up  to  254  octets,  except  for  data 
records  which  will  support  strings  with  a 
length  up  to  32  767  octets. 


I  B.4    Interoperability  with  SGML  applications 

The  recommended  method  for  the  exchange  of  documents  between  standard 
Generalized  Markup  Language  (ISO  8879,  SGML)  based  systems  and  systems  based  on 
i  this  ODA  document  application  profile  is  by  means  of  exchanging  a  document 
representation  conforming  to  these  agreements  in  an  encoded  form  of  the  SGML 

I  language  known  as  the  office  Document  Language  (ODL) .    ODL  is  a  standardized 

j  SGML  application  for  representing  documents  conforming  to  the  ODA  base  standard, 
j  Such  a  representation  may  be  converted  into  the  Office  Document  Interchange 

II  Format  (ODIF)  supported  by  this  document  application  profile. 
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Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Network  Management  Special  Interest 
Group  (NMSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW).  See  Procedures  Manual 
for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces  the 
previously  existing  chapter  on  this  subject. 

To  highlight  textual  changes  since  the  last  Workshop  output,  additions  to  the  text  in  this  part  are  marked  with 
shading;  deleted  text  is  left  in  but  marked  with  strikeouts. 
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18  Network  Management 


0  Introduction 

Within  the  community  of  OSI  researchers,  users,  and  vendors,  there  is  a  recognized  need  to  address  the 
problems  of  initiating,  terminating,  monitoring,  and  controlling  communication  activities  and  assisting  in  their 
harmonious  operation,  as  well  as  handling  abnormal  conditions.  The  activities  that  address  these  problems 
are  collectively  called  network  management. 

Network  management  can  be  viewed  as  the  set  of  operational  and  administrative  mechanisms  necessary  to: 

a.  bring  up,  enroll,  and/or  alter  network  resources; 

b.  keep  network  resources  operational; 

0.       fine  tune  these  resources  and/or  plan  for  their  expansion; 

d.  manage  the  accounting  of  their  usage; 

e.  manage  their  protection  from  unauthorized  use/tampering. 

As  such,  network  management  is  typically  concerned  with  management  activities  in  at  least  the  following  five 
functional  areas:  configuration  management,  fault  management,  performance  management,  accounting 
management,  and  security  management.  In  order  to  accomplish  these  management  activities,  information 
must  be  exchanged  among  open  systems. 

In  Part  18,  there  are  Implementation  Agreements  (lA's)  for  providing  interoperable  OSI  management 
information  communication  services  among  OSI  systems.  Also  contained  here  are  agreements  on 
management  information.  These  agreements  pertain  to  the  exchange  of  management  information  and 
management  commands  between  open  systems  operating  in  a  multivendor  environment.  For  example,  one 
goal  is  to  ensure  that  a  management  system  built  by  one  vendor  can  manage  objects  built  by  another  vendor. 
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1  Scope 

The  purpose  of  this  Part  (Part  18),  is  to  provide  implementation  agreements  that  will  enable  independent 
vendors  to  supply  customers  with  a  diverse  set  of  networking  products  that  can  be  managed  as  part  of  an 
integrated  environment.  Where  possible,  these  agreements  are  based  upon  OSI  Systems  Management 
standards. 


1.1       Phased  Approach 

Because  of  the  broad  scope  of  the  subject,  and  given  that  OSI  Systems  Management  standards  are  still 
evolving,  it  is  reasonable  to  assume  that  a  comprehensive  set  of  network  management  implementation 
agreements  will  take  a  number  of  years  to  develop.  To  arrive  at  an  initial  set  of  implementation  agreements 
in  a  timely  fashion,  a  phased  approach  has  been  adopted. 

This  phased  work  approach  will  result  in  a  series  of  implementation  agreements  based  on  the  expanding  scope 
of  the  OSI  Systems  Management  standards.  It  is  the  intention  of  the  NMSIG  to  define  the  content  of  each 
phase  as  a  compatible  superset  of  the  previous  Phases  to  ensure  that  Phase  N  products  can  Interact  with 
products  based  on  the  implementation  agreements  of  earlier  phases. 


1.1.1       Alignment  With  Evolving  Standards 

In  some  cases,  these  phased  implementation  agreements  may  be  based  on  DIS  standards.  As  the  relevant 
standards  progress  from  DIS  to  IS,  the  agreements  will  be  aligned  in  future  phases. 

When  a  defect  is  found  in  any  of  the  management  related  standards,  the  reported  defect  may  be  technically 
resolved  by  the  appropriate  international  technical  committee  with  likely  approval  by  the  voting  members 
pending  for  several  months.  Since  relevant  defects  can't  be  ignored  in  an  implementation,  these  agreements 
will  note  defect  resolutions  which  have  the  tentative  approval  of  the  appropriate  standards  committee.  These 
interim  resolutions  will  be  recorded  in  clause  4. 

Once  a  defect  resolution  has  been  completed  by  the  appropriate  standards  body,  the  agreed  upon  resolution 
will  be  incorporated  into  the  next  phase  of  these  implementors  agreements.  If  appropriate,  a  previous  phase 
that  relied  on  an  interim  resolution  will  be  examined  to  determine  whether  errata  sliould  be  issued  to  bring  the 

original  phase  into  line  with  the  final  resolution. 


1.1.2       Definition  of  Phase  1 

As  a  first  step  in  this  phased  approach,  the  NMSIG  has  targeted  an  initial  set  of  agreements  that  provide  limited 
interoperable  management  in  a  heterogeneous  vendor  environment.  They  are  the  beginning  of  a 
comprehensive  set  of  implementation  agreements  based  on  the  emerging  OSI  Systems  Management 
standards.  Furthermore,  these  initial  agreements  allow  the  community  to  gain  experience  with  OSI 
management  standards  as  they  emerge. 
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The  focus  of  the  Phase  1  agreements  is  to  enable  a  managing  process  provided  by  one  vendor  to  interoperate 
with  an  agent  process  provided  by  a  different  vendor  to  perform  limited  management  on  a  set  of  managed 
objects. 

The  scope  of  Phase  1  implementation  agreements  is  the  following: 

Management  Functions: 

Object  Management  Function  [OMF], 

State  Management  Function  [STMF], 

Attributes  For  Representing  Relationships  [ARR], 

Alarm  Reporting  Function  [ARF], 

Event  Report  Management  Function  [ERMF]. 

Management  Information: 

Information  Model,  Naming,  Guidelines  and  Templates  for  Defining  Managed  Objects 
Management  Communication: 

CMIS/P,  Association  Policies,  and  Upper  Layer  Services  Required 
Management  Objects: 

Support  Objects  required  for  the  above. 

Editor's  Note:  [The  relation  of  the  MIL  definitions  in  Annex  A  of  the  Working  Document  to  Phase 
1  lA's  needs  to  be  clarified.] 

Conformance  Criteria: 

Conformance  Criteria  for  the  above  functionality. 

To  accomplish  these  goals  in  a  timely  fashion,  the  following  simplifying  constraints  have  been  reflected  in  the 
Phase  1  agreements: 

1.  No  agreements  are  provided  regarding  management  domains; 

2.  These  agreements  require  only  the  following  application  service  elements:  the  Association 
Control  Service  Element  (ACSE).  the  Common  Management  Information  Sery/ice  Element 
(CMISE),  Remote  Operations  Service  Element  (ROSE),  and  the  System  Management  Application 
Service  Element  (SMASE); 

3.  These  agreements  do  not  require  implementation  of  services  defined  by  the  Directory  standards; 
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4.   No  agreements  regarding  the  security  of  nnanagement  are  provided. 


1.1.3       Future  Phases 

It  is  the  intention  of  the  NMSI6  to  freeze  the  content  of  Phase  1  when  these  agreements  are  progressed  to 
Stable  status.  Alignment  changes  required  as  the  standards  progress  from  DSS  to  SS  will  be  made  In  future 
phases. 

As  standards  defining  new  functionality  are  progressed,  the  NMSIG  will  define  future  phases  incorporating  the 
new  functionality  as  a  compatible  superset  of  previous  phases. 


2    Normative  References 

The  following  documents  are  referenced  in  the  statements  of  the  agreements  relating  to  OSI  systems 
management. 

Editor's  Note:  [Items  marked  with  an  asterisk,  "*",  are  ones  which,  while  not  cited  in  the  text  of  this  part 
of  the  lAs.  are  included  here,  nevertheless,  to  indicate  where  useful  background  information 
can  be  found.] 

ISO  8650,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Protocol 
Specification  for  the  Association  Control  Service  Element  (Revised  Final  Text  of  DIS  8650), 
ISO/IEC  JTC1/SC21  N2327,  21  April  1988. 

ISO  8649,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Service 
Definition  for  the  Association  Control  Service  Element  (Revised  Final  Text  of  DIS  8649), 
ISO/IEC  JTC1/SC21  N2326,  21  April  1988. 

ISO/IEC  9596/DAD  2,  Common  Management  Information  Protocol  Specification:  Addendum 
2  (Add/Remove  Protocol),  ISO/IEC  JTC1/SC21. 1  February  1990. 

ISO/IEC  9595/DAD  2,  Common  Management  Information  Service  Definition:  Addendum  2 
(Add/Remove  Service),  ISO/IEC  JTC1/SC21, 1  February  1990. 

ISO/IEC  DIS  9545,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Application  Layer  Structure,  15  March  1989. 

ISO/IEC  ISP  1 1 183-1,  Information  Technology  -  International  Standardized  Profiles  A0M1n 
OSI  Management  -  Management  Communications  -  Part  1:  Specification  of  ACSE, 
Presentation  and  Session  Protocols  for  the  use  by  ROSE  and  CMISE,  May  1992. 

ISO/IEC  ISP  1 11 83-3,  Information  Technology  -  International  Standardized  Profiles  AOMin 
OSI  Management  -  Management  Communications  -  Part  3:  CMISE/ROSE  for  A0M1 1  -  Basic 
Management  Communications,  May  1992. 


[ACSEP] 

[ACSESr 

[ADDRMVP] 
[ADDRMVS] 

[ALSr 
[A0M1PT1I 

[A0MlPT3j 
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[A0M1 PT2]  ISO/IEC  ISP  1 1 1 83-2,  Information  Technology  -  International  Standardized  Profiles  A0M1  n 
OSI  Management  -  Management  Communications  -  Part  2:  CMISE/ROSE  for  A0M12  - 
Enhanced  Management  Communications,  May  1992. 

[A0M21 1]  pDISP  12060-1 ,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  1 :  A0M21 1  -  General  Management  Capabilities, 
July  1992. 

[AOM212]  pDISP  12060-2,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  2:  AOM212  -  Alarm  Reporting  and  State 
Management  Capabilities,  July  1992. 

[AOM2131  pDISP  12060-3,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  3:  A0M21 3  -  Alarm  Reporting  Capabilities,  July 
1992. 

[A0M221  ]  pDISP  1 2060-4,  Information  Technology  -  International  Standardized  Profiles  -  A0M2nn  OSI 
Management  -  Management  Functions  -  Part  4:  AOM221  -  General  Event  Report 
Management,  July  1992. 

[AOM231]  pDISP  12060-5,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  5:  AOM231  -  General  Log  Control  Profile,  July 
1992. 

[ARF]  ISO/IEC  IS  10164-4,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  4:  Alarm  Reporting  Function,  ISO/IEC  JTCVSC21  N6359,  August  19, 
1991. 

[ARR]  ISO/IEC  IS  10164-3.  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management -Part  3:  Attributes  for  Representing  Relationships,  ISO/IEC  JTC1/SC21  N5186, 
September  1991. 

[ASN1]*  ISO/IEC  8824,  Information  Technology  -  Open  System  Interconnection  -  Specification  of 
Abstract  Syntax  Notation  One  (ASN.1).  ISO/IEC  JTC1/SC21  N4720,  30  April  1990. 

[BER]  ISO/IEC  8825,  Information  Technology  -  Open  Systems  Interconnection  -  Specification  of 

Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.  1 ),  ISO/IEC  JTCl  /SC21  N4721 , 
30  April  1990. 

[CANGETP]  ISO/IEC9596/DAD 1 ,  Common  Management  Information  Protocol  Specification:  Addendum 
1  (CancelGet  Protocol).  ISO/IEC  JTC1/SC21. 1  February  1990. 

[CANGETS]  ISO/IEC  9595/DAD  1.  Common  Management  Information  Service  Definition:  Addendum  1 
(CancelGet  Service),  ISO/IEC  JTC1/SC21, 1  February  1990. 


5 


PARTIS:  Network  Management 


December  1992  (Stable) 


[CMIP]  ISO/IEC  9596-1,  Information  Technology  -  Open  Systems  Interconnection  -  Common 

Management  Information  Protocol  Specification  -  Part  1 :  Specification,  24  November  1990. 

[CMIS]  ISO/IEC  9595,  Information  Technology  -   Open  Systems  Interconnection  -  Common 

Management  Information  Service  Definition,  Common  Management  Information  Service,  24 
November  1990. 

[Dl R] *  ISO  9594  - 1 nf ormation  Processing  Systems  -  Open  Systems  I nterconnection  -  The  Directory, 

1988. 

[DMI]  ISO/IEC  IS  10165-2,  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of 

Management  Information  -  Part  2:  Definition  of  Management  Information,  ISO/IEC 
JTC1  /SC21  N6363,  August  1991 . 

[ENSCON]*  Forum  025,  The  "Ensemble"  Concepts  and  Format,  Issue  1 .0,  Network  Management  Forum, 
July  1992. 

[ERMF]  ISO/IEC  IS  10164-5,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  5:  Event  Report  Management  Function,  ISO/IEC  JTC1/SC21  N6360, 
August  1991. 

[FRMWK]*  ISO  7498-4,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic 
Reference  Model  -  Part  4:  Management  Framework,  1989. 

[GDMO]  ISO/IEC  IS  10165-4,  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of 

Management  Information  -  Part  4:  Guidelines  for  the  Definition  of  Managed  Objects,  ISO/IEC 
JTC1/SC21  N6309,  July  30,  1991. 

[ISPARR3]  pDISP  12059-3,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  3:  Attributes  for 
Representing  Relationships,  July  1992. 

[ISPAR4]  pDISP  12059-4,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  4:  Alarm  Reporting, 
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[ISPCOMO]  pDISP  12059-0,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  0:  Common  Definitions 
for  Management  Function  Profiles,  July  1992. 

[ISPERM5]  pDISP  12059-5,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  5:  Event  Report 
Management,  July  1992. 

[ISPFRM]  ISO/IEC  TR  10000-1 ,  Information  Technology  -  Framework  and  Taxonomy  of  International 
Standardized  Profiles  -  Part  1 :  Framework,  ISO/IEC  JTC1  /SGFS  N184,  9  February  1990. 
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Management  -  Common  Information  for  Management  Functions  -  Part  6:  Log  Control,  July 
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[ISPSRVC]  ISO/IECTR  8509,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Service 
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Management  Forum,  August  1992. 

[PPS]*  ISO/IEC  DIS  8823,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 

Connection  Oriented  Presentation  Protocol  Specification,  ISO/IEC  JTCl  /SC21 N2336, 5  April 
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[SARF]  ISO/IEC  IS  10164-7,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 
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3  Status 

As  of  September  1 991 ,  the  Stable  management  communications  agreements  in  clause  6  of  part  1 8  and  clause 
1 3.7  of  part  5  became  technically  equivalent  to  DISP 1 1 1 83.  The  DISP.  however,  is  a  more  rigorous  statement 
of  specifications.  Therefore,  it  has  been  the  stated  intent  of  the  NMSIG  to  directly  reference  the  ISP  1 1 183, 
Parts  1  through  3.  and  all  the  agreements  therein,  when  the  DISP  reaches  ISP  status.  Since  the  DISP  has  now 
progressed  to  ISP  11183  with  no  technical  changes,  the  NMSIG  Stable  management  communications 
agreements  in  clause  6  of  part  18  have  now  been  changed  to  point  directly  to  ISP  11183-1  through  -3 
[A0M1PT1,  A0M1PT2,  and  A0M1PT21. 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  status  information.) 
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4  Errata 

Editor's  Note:  [  "Defect  Report"  material  (including  applicability)  may  be  Included  here.] 


The  following  table  indicates  the  clause,  type,  and  reference  document  of  technical  errata  to  this  part. 


crraiuiTi 
No. 

1  ype  <x 
Date 
Entered 

neTerenceu 
Document 

OlaUSe 

oommeni 

1 

Technical 
6/91 

NMSIG- 
91/08 

6.4.5 

This  clause,  previously  clause  6.2.6, 
was  modified  and  moved  to  clause 
6.4.5  to  clarify  that  it  is  Intended  as  a 
support  agreement  for  CMIP  rather 
than  a  usage  agreement  for  CMIS. 

2 

Alignment 
9/91 

NMSIG- 
91/110 
NMSIG- 
91/113 

5 

This  clause  has  been  updated  to 
reflect  alignment  changes  to  the 
relevant  base  standards  which  have 
just  progressed  to  IS  as  of  August, 
1991. 

3 

Technical 
9/91 

NMSIG- 
91/161 

6.2.2.2 

Move  text  from  clause  5.1.2.1  to 
more  appropriate  clause  6.2.2.2  and 
clarify  required  support  for  minimal 
filter  complexity  to  align  with  the  DISP 
11183. 

4 

Technical 
9/91 

NMSIG- 
91/161 

6.2.3 

Remove  unnecessary  restrictions  on 
sending  CMIP  time  parameters. 

5 

Alignment 
9/91 

NMSIG- 
91/114 

6.1.1 

Change  reference  to  required 
application  context  support  to  align 
with  IS  version  of  [SMO]. 

6 

Technical 
9/91 

NMSIG- 
91/161 

6.3.3.1 

Remove  clause  requiring  mandatory 
attribute  list  in  successful  set 
response  because  considered 
redundant  information. 
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Erratum 
No. 

Type  & 
Date 
Emered 

Referenced 
Document 

Clause 

Comment 

7 

Alignment 
9/91 

NMSIG- 
91/120 

7 

Update  clause  to  reflect  alignment 
changes  to  the  relevant  base 
standards  which  have  progressed  to 
IS  as  of  August,  1991. 

8 

Editorial 
9/91 

NMSIG- 
91/161 

6.3.6.1 

Move  clause  6.3.6.1  to  more 
appropriate  location  at  clause  7.1.5. 

9 

Alignment 
3/92 

NMSIG- 
92/066 

6.1.3 

Update  reference  because  number  of 
clause  in  other  part  of  OIW  Stable 
Agreements  changed. 

10 

Alignment 

6/92 

NMSIG- 
y2/(jyo 

5.2  -  5.7 

Update  text  to  reference  appropriate 
MUM^x  puiorS  oecause  nave 
equivalent  agreements,  but  are  more 
rigorous. 

11 

Alignment 

NMSIG  - 

6 

Update  text  to  reference  ISP  1 1 183 

wniun  lo  i6or iiiiudiiy  c^v^uivctit^iii  wiiii  im 

text  but  is  more  rigorous. 

12 

Technical 

12/92 

NMSIG- 

92/409 

A.5.1.2 

Modify  package  name, 
iransporiuonrieciionneiransrriissiorii  v 
MO-Package,  which  was  incorrectly 
specified  in  the  CHARACTERIZED  BY 
clause  of  the  MO  class  definition. 

13 

Technical 
12/92 

NMSIG- 
92/409 

A.5.1.2 

Modify  object  ID  in  REGISTERED  AS 
clause  of  the  MO  class  definition  to 
register  the  newly  modified  MO  (see 
erratum  12). 

14 

Technical 
12/92 

NMSIG- 
92/409 

B.3.1 

Modify  object  identifier  value  in 
TABLE  B.10  to  reflect  changes  in  MO 
definition  (see  errata  12  and  13). 

15 

Technical 
12/92 

NMSIG- 
92/409 

C.4.9 

Modify  object  identifier  value  in  the 
table  to  reflect  changes  in  MO 
definition  (see  errata  12  and  13). 
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5     Management  Functions  and  Services 


5.1 


General  Agreements 


5.1.1 


Conventions  Used  In  SMF  Agreements 


Each  System  Management  Function  defines  a  set  of  services  referred  to  in  this  document  as  "SMF  services." 
Agreements  pertinent  to  SMF  services  are  provided  in  the  following  subclauses.  Each  subclause  contains  a 
series  of  tables,  as  follows. 

For  each  SMF  sen/ice,  a  normative  table  references  text  agreements  which  constrain  the  usage  and /or  value 
of  the  associated  service  parameters.  Text  agreements  defined  elsewhere  in  this  document  are  referenced  by 
clause  number.  The  lack  of  a  row  or  reference  signifies  no  agreement  beyond  the  base  standard. 

These  tables  include  codes  which  specify  parameter  usage  for  request,  indication,  response,  and  confirmation 
service  primitives.  These  codes,  defined  in  subclause  1.8.3  of  these  agreements  (Classification  of 
Conformance),  in  ISO/IECTR 10000-1  (Framework  and  Taxonomy  of  ISPs)  [ISPFRM],andinlSO/IECTR8509 
(Service  Conventions)  [ISPSRVC],  are  repeated  here  for  reader  convenience: 


M  Mandatory 

0  Optional 

C(p)    If  Condition  p  exists,  then  parameter  is  mandatory;  otherwise,  the 

parameter  is  not  applicable. 
X  Excluded 

1  Out  Of  Scope 

In  these  agreements,  this  means  that,  for  the  corresponding  element, 

*  implementations  may  use  it  outside  the  scope  of  these  agreements, 

*  conformance  tests  shall  not  be  provided  for  it, 

*  implementations  may  conform  to  other  agreements  where  it  is  required, 

*  no  requirements  are  placed  on  either  transmitter  or  receiver  to  support 
it, 

*  receiver  actions  are  unspecified  when  present. 
Not  Applicable 

(=)  The  value  of  the  parameter  is  identical  to  the  corresponding  parameter  in 
the  interaction  described  by  the  preceding  related  service  primitive. 

U       The  use  of  the  parameter  is  a  service-user  option. 

P  The  parameter  is  mapped  directly  onto  the  corresponding  parameters  of 
the  CM  IS  service  primitive;  refer  to  subclause  6  for  agreements  regarding 
this  pass-through  parameter. 
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In  addition,  the  convention  "A>  B"  is  used  in  normative  tables  to  indicate  both  the  usage  specified  by  the  base 
standard  (A)  and  the  additional  constraint  imposed  by  these  agreements  (B).  This  convention  is  intended  to 
call  attention  to  agreements  which  modify  the  usage  of  a  sen/ice  parameter. 

Unless  otherwise  noted,  conditional  parameters  (C)  shall  be  present  according  to  the  conditions  defined  in 
[CMIS]  and  the  referenced  System  Management  Function  base  standard. 


5.1.2       General  Agreements  Referenced  By  Many  SMF  Services 

The  following  general  agreements  pertain  to  some  or  all  of  the  System  Management  Function  services  defined 
throughout  clause  5.  Normative  tables  for  each  SMF  service  reference  these  general  agreements  where 
applicable.  These  agreements  do  not  apply  to  SMF  services  and  parameters  which  do  not  reference  them. 


5.1.2.1         Maximum  Lengtii  of  Notification  Identifier 

To  limit  implementation  complexity,  the  maximum  length  of  the  Notification  Identifier  parameter  shall  be  32  bits. 


5.1.2.2        Maximum  Number  of  SET  Items 

To  limit  implementation  complexity,  the  maximum  number  of  SET  items  contained  within  specified  SMF  service 
parameters  that  recipients  must  be  able  to  process  shall  be  64. 


5.1.2.3        Maximum  Lengthi  of  Additional  Text 

To  limit  implementation  complexity,  the  maximum  length  of  the  Additional  Text  parameter  which  recipients 
must  be  able  to  process  shall  be  256  octets. 


5.1.2.4        Use  of  Additional  Info 

Editor's  Note:  [The  Additional  Information  parameter,  described  in  [ARF]  clause  8.1.2.14,  includes  a 
"significance  indicator."  It  requires  that  "[e]ven  if  the  Additional  Information  parameter  is  not 
fully  understood,  an  event  report  indication  shall  be  issued  to  the  user.  Indication  that  the 
Additional  Information  parameter  is  not  fully  understood  is  a  local  matter."] 
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5.2       Object  Management  Function  Agreements 


5.2.1  General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  object  management  standard  [OMFJ.  ; 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  object  I 
management  standard  [OMF]  and  specified  in  [DMI],  with  the  exception  of  event  record  subclasses.  If  support  ] 
for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [OMF]  event  record  ! 
subclasses  shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the  i 
system  management  functional  units  specified  in  clause  10  of  [OMF].  ^ 

s 

5.2.2  Specific  Agreements 

\ 

See  [ISPOMi  ]  for  specification  of  agreements  for  the  Object  Management  Function. 


5.3       State  Management  Function  Agreements 


5.3.1  General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  state  management  standard  [STMF].  ! 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  state  j 

management  standard  [STMF]  and  specified  in  [DMI],  with  the  exception  of  event  record  subclass.  If  support  ] 

for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [STMF]  event  record  ^ 

subclasses  shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the  j 

State  Change  Reporting  functional  unit  specified  in  clause  10  of  [STMF].  , 

I 

5.3.2  Specific  Agreements 

See  [ISPSTM2]  for  specification  of  agreements  for  the  State  Management  Function.  | 


I 


14 


PART  18:  Network  Management 


December  1992  (Stable) 


5.4       Attributes  For  Representing  Relationships  Agreements 


5.4.1       General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  Attributes  For  Representing 
Relationships  standard  [ARR]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  attributes 
for  representing  relationships  standard  [ARR]  and  specified  in  [DMI],  with  the  exception  of  event  record 
subclass.  If  support  for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [ARR] 
event  record  subclasses  shall  also  be  required  by  these  agreements.  These  agreements  permit  optional 
negotiation  of  the  Relationship  Change  Reporting  functional  unit  specified  in  clause  10  of  [ARR]. 


5.4.2       Specific  Agreements 

See  [ISPARR3]  for  specification  of  agreements  for  Attributes  for  Representing  Relationships. 


5.5       Alarm  Reporting  Function  Agreements 


5.5.1       General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  alarm  reporting  standard  [ARF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  alarm 
reporting  standard  [ARF]  and  specified  in  [DMI],  with  the  exception  of  event  record  subclass.  If  support  for 
the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [ARF]  event  record  subclasses 
shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the  Alarm 
Reporting  functional  unit  specified  in  clause  10  of  [ARF]. 


5.5.2       Specific  Agreements 

See  [ISPAR4]  for  specification  of  agreements  for  the  Alarm  Reporting  Function. 
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5.6 


Event  Report  Management  Function  Agreements 


5.6.1 


General  Agreements 


These  agreements  require  support  for  the  SMF  services  defined  by  the  event  report  management  standard 
[ERMF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  event  report 
management  standard  [ERMF]  and  specified  in  [DMI].  These  agreements  permit  optional  negotiation  of  the 
Monitor  Event  Report  Management  and  Event  Report  Management  functional  units  specified  in  clause  10  of 
[ERMF]. 


5.6.2       Specific  Agreements 

See  [ISPERM5]  for  specification  of  agreements  for  the  Event  Report  Management  Function. 


5.7       Log  Control  Function  Agreements 


5.7.1        General  Agreements 

These  agreements  require  the  SMF  services  defined  by  the  log  control  standard  [LCF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  log  control 
standard  [LCF]  and  specified  in  [DMI]. 

If  any  other  function  defined  in  clause  5  that  supports  notifications  is  supported,  then  any  event  record  subclass 
defined  by  that  function  is  required  for  the  log  control  function. 

These  agreements  permit  optional  negotiation  for  log  control  and  monitor  log  control  functional  units  specified 
in  section  10  of  [LCF]. 

The  appropriate  CMIS  error  (i.e.,  invalidAttributeValue)  shall  be  returned  for  any  attempt  to  set  Max  log  size  less 
than  the  value  of  Current  log  size,  except  if  setting  the  Max  log  size  to  zero.  When  the  Max  log  size  is  set  to 
zero,  then  the  maximum  log  size  is  unlimited. 
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I  5.7.2       Specific  Agreements 

See  [ISPLC6]  for  specification  of  agreements  for  the  Log  Control  Function. 

5.8       Security  Alarm  Reporting  Function  Agreements 
5.8.1       General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  security  alarm  reporting  standard 
i  [SARF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  alarm 
reporting  standard  [SARF]  and  specified  in  [DM!],  with  the  exception  of  event  record  subclass.  If  support  for 
the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [SARF]  event  record  subclasses 
shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the  security 
alarm  reporting  function  as  specified  in  section  10  of  [SARF]. 


5.8.2       Security  Alarm  Reporting 

This  subclause  provides  agreements  pertinent  to  the  Security  Alarm  Reporting  SMF  service  defined  by  section 
9.2  of  [SARF].  Subclause  6  provides  agreements  pertinent  to  CMIS  services  and  pass-through  parameters 
used  by  this  SMF  sen/ice. 


Table  1  -  Agreements  on  parameter  usage  pertinent  to  the  Security  Alarm  Reporting  SMF  service 


SMF  Security  Alarm  Reporting 
parameter 

Req 

Rsp 

SMF  agreements 

Event  Type 

M 

C(=) 

Event  Information 

Security  Alarm  Cause 

M 

Security  Alarm  Severity 

M 

Security  Alarm  Detector 

M 

[1] 

Service  User 

M 

Service  Provider 

M 

Notification  Identifier 

U 

5.1.2.1 
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SMF  Security  Alarm  Reporting 
parameter 

Req 

Rsp 

SMF  agreements 

Correlated  Notifications 

U 

5.1.2.2 

Additional  Text 

U 

5.1.2.3 

Additional  Info 

u 

5.1.2.2,  5.1.2.4 

[1]  To  avoid  ambiguity,  the  Distinguished  Name  form  of  this  parameter  shall  be  implemented  and 
may  be  used.  Use  of  Local  Distinguished  Name  and  Non-Specific  forms  are  beyond  the  scope 
of  these  agreements.  If  an  implementation  is  unable  to  decode  or  understand  the  semantics 
of  this  parameter,  an  appropriate  CMIS  error  (i.e.,  Invalid  Attribute  Value)  shall  be  returned. 


5.9       Security  Audit  Trail  Function  Agreements 


5.9.1        General  Agreements 

These  agreements  require  support  for  the  SMF  sen/ices  defined  by  the  security  audit  trail  standard  [SATF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  11 .2  of  the  security 
audit  trail  standard  [SATF]  and  specified  in  [DMI],  with  the  exception  of  event  log  record  subclass.  If  support 
for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [SATF]  event  log  record 
subclasses  shall  also  be  required  by  these  agreements. 


5.9.2       Security  Audit  Trail  Reporting  SMF  Service 

This  subclause  provides  agreements  pertinent  to  the  Security  Audit  Trail  Reporting  SMF  service  defined  by 
section  9.2  of  [SATF] .  Clause  6  provides  agreements  pertinent  to  CMIS  services  and  pass-through  parameters 
used  by  this  SMF  service. 

Table  2  -  Agreements  on  parameter  usage  pertinent  to  the  Security  Audit  Trail  Reporting  SMF 

service 


SMF  Security  Audit  Trail  parameter 

Req 

Rsp 

SMF  agreements 

Event  Type 

M 

C(=) 

5.9.2.1 

Event  Information 

Service  Report  Cause 

C(1) 
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SMF  Security  Audit  Trail  parameter 

Req 

Rsp 

SMF  agreements  | 

Notification  Identifier 

U 

5.1.2.3  1 

Correlated  Notifications 

U 

5.1.2.4  1 

Additional  Text 

u 

5.1.2.5 

Additional  Info 

U>l 

5.1.2.6 

C(1):  Manadatory  (M)  for  serviceReport 


5.9.2.1  Notifications 

These  Implementors'  Agreements  require  support  for  both  the  sevlceReport  and  usageReport  notification 
types. 

5.9.3       Security  Audit  Trail  Record 

This  subclause  is  a  placeholder  for  agreements  pertaining  to  the  Security  Audit  Trail  Record  (SATR)  managed 
object  class. 

5.10  Objects  and  Attributes  for  Access  Control  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

5.11  Accounting  Meter  Function  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

5.12  Workload  Monitoring  Function  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

i 

I 
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5.13  Summarization  Function  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

5.14  Test  Management  Function  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

5.15  Confidence  and  Diagnostic  Test  Classes  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

6    Management  Communications 

This  clause  covers  the  agreements  pertaining  to  the  use  of  associations  over  which  to  conduct  management 
communications,  and  agreements  for  management  communication,  itself,  by  reference  to  ISP  11183 
[A0M1PT1.  A0M1PT2.  and  A0M1PT3].  ISP  11183  defines  two  profiles.  A0M11  (Basic  Management 
Communications)  [A0M1PT3]  and  A0M12  (Enhanced  Management  Communications)  [A0M1PT2],  and 
defines  upper  layer  requirements  [AOMI PTI  ]  for  each  of  these  profiles. 

For  rigorous  specification  of  the  agreements  relevant  to  clause  6,  Management  Communications,  see  ISP 
11183  [A0M1PT1.  AOMI  PT2,  and  AOMI PT3]. 

6.1       Association  Policies 

Associations  are  established  using  the  procedures  described  in  [ACSEP]. 

6.1.1  Application  Context  Negotiation 

These  I  As  specify  the  negotiation  of  the  Systems  management  application  context  specified  in  [SMO].  Other 
application  contexts  are  outside  the  scope  of  these  agreements. 

6.1.2  Functional  Unit  Negotiation 

These  lAs  specify  that  System  Management  Functional  Units  are  negotiated  as  specified  In  [SMO]. 
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1 6.1.3       Security  Aspects  of  Associations 

'  The  ACSE  authentication  mechanisms  and  associated  data  types  shall  be  as  defined  in  clause  9  (Upper  Layers 
j  Security)  of  part  1 2  of  the  01 W  Working  Agreements. 

Support  of  ACSE  authentication  is  optional. 


7    Management  Information 

This  clause,  which  is  based  on  ISO  standards'  documents  [MIM]  and  [GDMO] ,  contains  agreements  regarding 
basic  concepts  and  modelling  techniques  related  to  management  information.  It  enumerates  agreements  on 
(i)  the  information  model  (subclause  7.1)  and  (ii)  guidelines  for  defining  management  information  (subclause 
7.2).  These  agreements  apply  to  developers  of  contributions  to  the  Management  Information  Library  (MIL). 
They  form  a  normative  part  of  the  standard;  hence  they  must  be  strictly  followed  while  defining  management 
information.  It  is  not  within  the  scope  of  this  clause  to  make  agreements  about  specific  elements  of 
management  information  or  to  define  such  specific  elements  of  management  information.  Such  definitions 
and/or  agreements  can  be  obtained  via  the  Management  Information  Library. 


7.1       The  Information  Model 

When  modelling  management  information,  these  agreements  require  use  of  [MIM]  with  the  following  additional 
constraints. 


7.1.1  Inheritance 

The  following  constraint  related  to  inheritance  is  enforced  in  order  to  remove  potential  ambiguities: 

During  the  lifetime  of  a  managed  object  instance,  each  of  its  attributes  must  have  a  value  that  is 
valid  for  the  attribute  syntax  of  that  attribute. 


7.1.2  Interoperability 


7.1.2.1         Interoperability  Provided  By  Tlie  Agent  System 

Allomorphism,  as  specified  in  clause  5.2.3.1  of  [MIM],  is  out  of  scope.  Any  other  specif ication  within  the  [MIM] 
or  [GDMO]  that  refers  to  allomorphism  is  also  out  of  scope. 
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7.1.2.2 


Interoperability  Provided  By  The  Manager  System 


The  semantics  of  clause  5.2.3.2  of  [MIM]  are  supported.  A  manager  system  can  supply  the  object  identifier 
as  specified  in  clause  7.4.5  of  [GDMO]  to  specify  that  a  managed  object  should  perform  an  operation  as  a 
member  of  its  actual  class.  The  object  identifier  is  intended  to  be  used  in  requests  only,  and  shall  be 
interpreted  by  the  responder  as  a  requirement  to  return  its  real  object  class  value  in  the  response.  Agent 
systems  shall  support  this  object  identifier  as  defined  in  [MIM]  5.2.3.2  and  [GDMO]  7.4.5. 


7.1  «3  Filter 

The  concept  of  filter  is  supported  as  specified  in  clause  6.  Restrictions  on  its  usage  are  specified  in  subclause 
6.2.2.2  of  these  agreements. 


7.1.4       Management  Operations 

An  implementation  that  complies  with  these  agreements  shall  support  management  operations  as  defined  in 
clause  5.3.4  of  [MIM]  with  the  following  additional  clarification. 

[MIM]  clause  5.3.4.1  (2),  [DMI]  clause  6.14,  and  [GDMO]  clause  6.1.4  imply  that  the  object  class 
attribute  shall  not  be  included  in  the  create  request  Attribute  List  parameter.  [MIM]  states  that  any 
conflicting  duplicate  specifications  cause  the  request  to  fail. 


7.1.5       Deletion  of  Objects  Containing  Objects 

The  error  'Processing  Failure"  shall  be  returned  if  a  managed  object  has  existing  contained  objects  and  the 
behavior  defined  for  that  object  prohibits  its  deletion  unless  all  contained  objects  have  been  deleted. 


7.2       Guidelines  for  the  Definition  of  Management  Information 

This  subclause  contains  agreements  about  guidelines  for  the  definition  of  management  information,  as 
specified  in  [GDMO]. 


7.2.1 


Syntactical  Definitions  of  Management  Information 


7.2.1.1 


Attribute  Template 


The  following  constraint  applies  to  the  Attribute  Template  specified  in  clause  9.7.2  of  [GDMO]: 
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The  BEHAVIOUR  construct  may  be  omitted  only  if  a  behaviour  definition  has  been  Inherited  from 
the  parent  attribute,  i.e.,  the  attribute  is  derived  from  another  attribute  whose  definition  contains  a 
BEHAVIOUR  construct. 


The  following  details  should  be  provided  in  the  set  of  specifications  defining  a  managed  object  class: 

a)  a  textual  description  of  the  network/system  resource(s)  the  managed  object  class  represents, 
including  their  functional  role; 

b)  a  description  of  the  relationships  that  can  occur  between  different  instances  of  the  managed 
object  class  being  defined,  as  well  as  those  that  can  occur  between  instances  of  the  managed 
object  class  being  defined  and  instances  of  other  managed  object  classes; 

c)  a  description  of  the  operations  that  are  supported  by  the  managed  object  class,  with  precise 
definition  of  the  effects,  side  effects  if  any,  constraints,  response  notifications,  failure  modes; 

d)  specification  of  how  instances  of  this  managed  object  class  are  created  and  deleted,  particularly 
whether  they  can  be  created /deleted  via  the  management  CREATE/DELETE  operations; 


e)  a  description  of  notifications  that  can  be  generated,  the  conditions  that  generate  them  (e.g., 
crossing  of  a  threshold),  their  contents  and  side-effects,  if  any.  In  particular,  identify  all  the 
attributes  that  are  subject  to  the  AttributeChange  and  StateChange  notifications,  if  these 
notifications  are  supported; 

f)  other  constraints,  including  those  involving  other  managed  object  classes. 


7.2.3       Other  Guidelines 

i|  The  Systems  Management  functions  have  defined  various  attributes  and  events,  as  indicated  in  clause  5  of 
1  these  agreements.  Object  definers  should  make  use  of  these  attributes  and  events  wherever  applicable. 


i 

i  7.2.2 


Guidelines  For  Defining  Behaviour 
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8  Conformance 


8.1  Introduction 

Clause  8  specifies  the  conformance  requirements  for  tfie  OIW  Network  Management  Implementation 
Agreements  (lAs).  Implementors  of  products  will  provide  claims  of  conformance  to  these  requirements.  These 
claims  will  be  in  the  form  of  Protocol  Implementation  Conformance  Statements  (PICS)  and  Managed  Object 
Conformance  Statements  (MOCS).  These  requirements  will  also  be  used  to  develop  test  cases  which  will  be 
used  to  validate  claims  of  conformance.  This  clause  defines  the  general  conformance  requirements  and 
criteria  which  shall  be  used  as  a  basis  for  tests  of  implementations  claiming  conformance  to  these  agreements. 
Dependent  conformance  requirements  are  defined  in  the  context  in  which  they  are  used  (e.g.,  SMF  general 
conformance  requirements  include  CMIP  dependent  conformance  requirements  for  CMIS  services  used). 

Editor's  Note:  [The  use  of  the  two  terms,  "general  conformance  class"  and  "dependent  conformance 
class",  is  under  review.  When  a  final  answer  to  Question  Q1  /49.9  (on  the  long  term  solution 
to  general  and  dependent  conformance)  has  been  approved,  it  is  intended  to  clarify  and/or 
correct  this  conformance  section.] 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  introductory  text.) 


8.2       General  Requirements  of  Conformance 

Conformance  for  these  agreements  is  designed  to  specify  a  well-defined  set  of  management  capabilities  and 
features.  For  the  purposes  of  organization  and  clarity  of  these  agreements,  management  has  been  divided 
Into  three  categories.  Clauses  5  (Management  Functions  and  Services),  6  (Management  Communications) 
and  7  (Management  Information)  state  the  agreements  which  respectively  comprise  three  conformance 
categories.  Within  these  categories,  particular  conformance  categories  are  specified  which  delineate 
conformance  requirements  for  a  well-defined  and  bounded  set  of  management  capabilities  and  features  (e.g., 
within  the  Management  Functions  and  Services  conformance  categories,  a  conformance  category  is  specified 
which  defines  conformance  to  Alarm  Reporting  and  State  Management  Services).  Once  a  conformance 
category  is  delineated  which  specifies  the  set  of  requirements  for  that  category,  tests  can  be  developed  to 
evaluate  conformance  of  products  to  that  conformance  category.  And  finally,  for  some  conformance 
categories,  roles  (Manager,  Agent,  or  both)  are  specified.  One  or  more  roles  may  be  supported  for  those 
conformance  categories  to  which  an  implementation  is  conformant. 

The  development  of  conformance  categories  will  enable: 

a)  users  to  define  procurement  specifications; 

b)  vendors  to  define  management  capabilities  and  features; 

c)  conformance  test  houses  and  others  to  define  test  cases. 
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i 
[ 

To  be  conformant  to  the  I  As.  an  implementation  sliall  be  conformant  to  at  least  one  of  the  following  categories: 

a)  Management  Connmunlcation; 

b)  Management  Functions  and  Services; 

J         c)  Management  Information. 

i 

y  implementations  which  are  conformant  to  these  categories  shall  comply  with  the  requirements  stated  in  the 
y  following  clause. 

f 

1 8.3       Specific  Conformance  Categories 


j  8.3.1       Management  Communication  Categories 

i  To  be  conformant  to  the  Management  Communication  categories,  an  implementation  shall  conform  to 
I  i  agreements  in  clause  6.  Conformance  to  management  communication  also  requires  an  implementor  to  state 
j  i  which  of  the  management  communication  profiles  specified  in  clause  6  are  supported  in  the  implementation. 

The  implementor's  statement  of  which  profile  is  supported  shall  be  indicated  in  a  CMIP  PICS  as  follows.  The 
i  implementor  shall  complete  the  PICS  proforma  as  specified  by  one  of  the  profiles  specified  in  clause  6. 

ij  Note:  [Conformance  requirements  for  these  I  As,  relating  to  services  required  of  the  upper  layers  and 
•|  other  ASEs,  are  discussed  in  part  5,  clause  13.7] 

I 

1 8.3.2       Management  Functions  and  Services  Conformance  Categories 

I  To  be  conformant  to  the  Management  Functions  and  Services  categories,  an  implementation  shall  conform 
^  to  the  agreements  in  clause  5  on  at  least  one  of  the  categories  defined  below  in  either  a  manager  role,  an  agent 
'.^  role  or  both  roles.  [Note:  These  categories  are  aligned  with  the  proposed  A0M2x  Profiles  for  Systems 
^  Management  Functions.]  [NMSIG1]  Conformance  to  agreements  in  clause  5  requires  conformance  to 
q  referenced  ISO  standards/CCITT  Recommendations  and  to  all  other  clauses  referenced  in  5,  including 
[i  dependent  conformance  to  the  underlying  services  required  by  the  SMFs. 

'  The  implementor  shall  state  which  of  the  following  conformance  categories  are  supported.  For  each  category, 
'  the  implementor  shall  complete  the  related  PICS  and  MOCS  proformasto  indicate  which  functional  unit(s)  and 
role(s)  are  supported. 

I 

8.3.2.1        General  Management  Capabilities  Conformance  Category 

I  Note:   [This  category  corresponds  to  proposed  profile  A0M21 1  [A0M21 1].] 

ii 
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Conformance  to  the  General  Management  Capabilities  Conformance  Category  requires  general  conformance 
to  the  Object  Management  Function  [OMF],  general  conformance  to  the  State  Management  Function  [STMF], 
general  conformance  to  the  Attributes  for  Representing  Relationships  Function  [ARR],  and  general 
conformance  to  the  Alarm  Reporting  Function  [ARF].  To  be  conformant  to  the  Object  Management  Function, 
an  implementation  shall  conform  to  the  requirements  stated  in  [OMF].  In  addition,  an  implementation  shall 
conform  to  clause  5.2  of  these  agreements  and  all  other  clauses  referenced  in  5.2.  To  be  conformant  to  the 
State  Management  Function,  an  implementation  shall  conform  to  the  requirements  stated  in  [STMF].  in 
addition,  an  implementation  shall  conform  to  clause  5.3  of  these  agreements  and  all  other  clauses  referenced 
in  5.3.  To  be  conformant  with  the  Attributes  for  Representing  Relationships  Function,  an  implementation  shall 
conform  to  the  requirements  stated  in  [ARR],  In  addition,  an  implementation  shall  conform  to  clause  5.4  of 
these  agreements  and  all  other  clauses  referenced  in  5.4.  To  be  conformant  to  the  Alarm  Reporting  Function, 
an  implementation  shall  conform  to  the  requirements  stated  in  [ARF].  In  addition,  an  implementation  shall 
conform  to  clause  5.5  of  these  agreements  and  all  clauses  referenced  in  5.5. 


8.3.2.2  Alarm  Reporting  and  State  Management  Capabilities  Conformance  Category 
Note:    [This  category  corresponds  to  proposed  profile  AOM212  [AOM212].] 

Conformance  to  the  Alarm  Reporting  and  State  Management  Capabilities  Conformance  Category  requires 
general  conformance  to  the  State  Management  Function  [STMF],  general  conformance  to  the  Alarm  Reporting 
Function  [ARF],  and  dependent  conformance  to  the  Object  Management  Function  [OMF].  To  be  conformant 
to  the  State  Management  Function,  an  implementation  shall  conform  to  the  requirements  stated  in  [STMF]. 
In  addition,  an  implementation  shall  conform  to  clause  5.3  of  these  agreements  and  all  other  clauses 
referenced  in  5.3.  To  be  conformant  to  the  Alarm  Reporting  Function,  an  implementation  shall  conform  to  the 
requirements  stated  in  [ARF] .  In  addition,  an  implementation  shall  conform  to  clause  5.5  of  these  agreements 
and  all  clauses  referenced  in  5.5. 

Dependent  conformance  to  the  Object  Management  Function  required  by  the  Alarm  Reporting  and  State 
Management  Capabilities  Conformance  Category  requires  support  for  the  PT-SET  and  PT-GET  elements  of 
procedure  in  clauses  1 1 .1 .6  and  1 1 .1 .7  of  [OMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as 
specified  by  the  implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.2.7  and 
clause  5.2.9  of  these  agreements  and  all  clauses  referenced  in  5.2.7  and  5.2.9.  The  implementation  need  only 
support  the  PT-SET  and  PT-GET  elements  of  procedure  as  applied  to  the  State  Management  Attributes 
identified  in  [STMF]  and  specified  in  [DMIj.  An  implementation  shall  also  conform  to  the  notifications  identified 
in  [STMF]  and  specified  in  [DMI]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asn1(1)  basic  encoding(1)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  PT-GET  and  PT-SET  elements  of  procedure  as  defined  in  clauses 
11.1.6  and  11.1.7  of  [OMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asnl  (1 )  basic  encoding(l )] .  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.6  of  [STMF]. 
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8.3.2.3 


Alarm  Reporting  Capabilities  Conformance  Category 


Note:   [This  category  corresponds  to  proposed  profile  AOM213  [AOM213].] 

Conformance  to  the  Alarm  Reporting  Capabilities  Conformance  Category  requires  general  conformance  to  the 
Alarm  Reporting  Function  [ARF].  To  be  conformant  to  the  Alarm  Reporting  Function,  an  implementation  shall 
conform  to  the  requirements  stated  in  [ARF].  In  addition,  an  implementation  shall  conform  to  clause  5.5  of 
these  agreements  and  all  clauses  referenced  in  5.5. 


8.3.2.4        General  Event  Report  Management  Conformance  Category 
Note:    [This  category  corresponds  to  proposed  profile  AOM221  [AOM221].] 

Conformance  to  the  General  Event  Report  Management  Conformance  Category  requires  general  conformance 
to  the  Event  Report  Management  Function  [ERMF],  dependent  conformance  to  the  Object  Management 
Function  [OMF],  and  dependent  conformance  to  the  State  Management  Function  [STMF].  To  be  conformant 
to  the  Event  Report  Management  Function,  an  implementation  shall  conform  to  the  requirements  stated  in 
[ERMF].  In  addition,  an  implementation  shall  conform  to  clause  5.6  of  these  agreements  and  all  clauses 
referenced  in  5.6. 

Dependent  conformance  to  the  Object  Management  Function  required  by  the  General  Event  Report 
Management  Conformance  Category  requires  support  for  the  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE, 
,  object  creation  reporting,  object  deletion  reporting,  andattributevaluechangereportingelementsof  procedure 
'  in  clauses  11.1.1  through  1 1 .1 .7  of  [OMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as  specified 
I  by  the  implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.2.2  through  clause 
I  5.2.7,  and  clause  5.2.9  of  these  agreements  and  all  clauses  referenced  in  these  clauses.  An  implementation 
j  shall  also  conform  to  the  notifications  identified  in  [OMF]  and  specified  in  [DMI]. 

Dependent  conformance  to  the  State  Management  Function  required  by  the  General  Event  Report 
Management  Conformance  Category  requires  support  for  the  state  change  reporting  elements  of  procedure 
in  clause  11.1  of  [STMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as  specified  by  the 
implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.3.2  of  these  agreements 
and  all  clauses  referenced  by  clause  5.3.2.  An  implementation  shall  also  conform  to  the  notifications  identified 
in  [STMF]  and  specified  in  [DMI]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asnl  (1)  basic  encoding(l)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  supportthe  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE,  object  creation  reporting, 
object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure  as  defined  in  clauses 
11.1.1  through  11.1.7  of  [OMF]. 


The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asnl  (1)  basic  encoding(l)],  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.5  of  [OMF]. 
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For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived  ■ 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asn1(1)  basic  encodlng(1)],  for  the  purpose  ! 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCr  abstract  syntax  I 
defined  In  [CMIP]  required  to  support  the  state  change  reporting  elements  of  procedure  as  defined  In  clause  i 

11.1  of  [STMF].  - 

■I 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  In  [BER]  named 
[joint-iso-ccitt  asnl  (1 )  basic  encoding (1 )],  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined  i 

by  the  abstract  data  types  referenced  in  1 1 .2.6  of  [STMF].  : 

I 

8.3.2.5        General  Log  Control  Conformance  Category  | 

Note:    P"his  category  corresponds  to  proposed  profile  AOM231  [AOM231].]  ^ 

Conformance  to  the  Log  Control  Conformance  Category  requires  general  conformance  to  the  Log  Control  i 
Function  [LCF|,  dependent  conformance  to  the  Object  Management  Function  [OMF],  dependent  conformance  i 
to  the  State  Management  Function  [STMF]  and  dependent  conformance  to  the  Alarm  Reporting  Function  ! 
[ARF].  To  be  conformant  to  the  Log  Control  Function,  an  implementation  shall  conform  to  the  requirements  ) 
stated  in  [LCF] .  I  n  addition,  an  implementation  shall  conform  to  clause  5.7  of  these  agreements  and  all  clauses  i 
referenced  in  5.7.  ,) 

Dependent  conformance  to  the  Object  Management  Function  required  by  the  General  Log  Control  i 
Conformance  Category  requires  support  for  the  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE,  object  creation  1 
reporting,  object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure  in  clauses  | 
11.1.1  through  1 1 .1 .7  of  [OMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as  specified  by  the  j 
implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.2.2  through  clause  5.2.7,  j 
and  clause  5.2.9  of  these  agreements  and  all  clauses  referenced  in  these  clauses.  An  implementation  shall  also 
conform  to  the  notifications  identified  in  [OMF]  and  specified  in  [DMI]. 

Dependent  conformance  to  the  State  Management  Function  required  by  the  General  Log  Control  Conformance  ^ 
Category  requires  support  for  the  state  change  reporting  elements  of  procedure  in  clause  1 1.1  of  [STMF]  in 
either  the  agent  role,  the  manager  role,  or  both  roles  as  specified  by  the  implementor  in  the  PICS.  In  addition, 
an  implementation  shall  conform  to  clause  5.3.2  of  these  agreements  and  all  clauses  referenced  by  clause 
5.3.2.  An  implementation  shall  also  conform  to  the  notifications  identified  in  [STMF]  and  specified  in  [DMI].  ' 

Dependent  conformance  to  the  Alarm  Reporting  Function  required  by  the  General  Log  Control  Conformance 
Category  requires  support  for  the  alarm  reporting  elements  of  procedure  in  clause  11.1  of  [ARF]  In  either  the 
agent  role,  the  manager  role,  or  both  roles  as  specified  by  the  implementor  in  the  PICS.  In  addition,  an 
implementation  shall  conform  to  clause  5.5.2  of  these  agreements  and  all  clauses  referenced  by  clause  5.5.2. 
An  implementation  shall  also  conform  to  the  notifications  identified  in  [ARF]  and  specified  in  [DMI]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asn1(1)  basic  encoding(l)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE,  object  creation  reporting, 
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■\t  object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure  as  defined  in  clauses 
J  11.1.1  through  11.1.7  of  [OMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
'  [joint-iso-ccitt  asnl  (1 )  basic  encoding(1 )],  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.5  of  [OMF]. 

(  For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
i  from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asm  (1)  basic  encoding(l)].  for  the  purpose 
I    of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 

;  defined  in  [CMIP]  required  to  support  the  state  change  reporting  elements  of  procedure  as  defined  in  clause 
11.1  of  [STMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
i  [joint-iso-ccitt  asnl  (1 )  basic  encoding(1 )],  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
j  by  the  abstract  data  types  referenced  in  1 1 .2.6  of  [STMF]. 

j  For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
j  from  the  encoding  rules  defined  in  [BER]  named  (joint-iso-ccitt  asnl  (1)  basic  encoding(l)],  for  the  purpose 
J  of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 

defined  in  [CMIP]  required  to  support  the  alarm  reporting  elements  of  procedure  as  defined  in  clause  1 1.1  of 

[ARF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
.  [joint-iso-ccitt  asnl  (1 )  basic  encoding(1 )] ,  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.5  of  [ARF]. 

J 

^  8.3.3       Management  Information  Conformance  Category 

1  To  be  conformant  to  the  Management  Information  Conformance  Category,  an  implementation  shall  include 
\'  at  least  one  managed  object  defined  as  specified  by  clause  7.  The  requirements  for  managing  this  managed 
J  object  shall  not  conflict  with  the  specifications  in  clauses  5  and  6.  Managed  object  class  definitions  shall  be 
ij  provided  either  in  full  or  by  reference.  Registered  object  identifiers  shall  be  associated  with  any  such  managed 
1  object  class  definition  and  supporting  definitions  (e.g.,  attributes,  name  bindings).  All  mandatory  abstract 
'  syntaxes  and  semantics  associated  with  those  identifiers  shall  be  used.  Note  that  all  managed  objects  and 
supporting  definitions  in  Annex  A  satisfy  these  conformance  requirements. 

An  implementation  is  conformant  to  a  managed  object  class  definition  if  it  supports  all  the  mandatory  packages 
specified  in  the  managed  object  class  as  well  as  all  associated  information  (e.g.,  attributes,  notifications, 
actions,  parameters)  referenced  in  these  packages  and  at  least  one  name  binding  that  may  be  used  to  support 
the  naming  of  instances  of  this  managed  object  class.  Although  it  is  not  necessary  to  be  conformant  to  all 
ijj  superior  object  classes  in  the  containment  tree  of  an  instance  of  a  conformant  managed  object  class,  all  name 
I  bindings  and  naming  attributes  necessary  to  access  that  object  instance  shall  be  publicly  available. 
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8.3.3.1         MOCS  Proforma 

The  implementor  shall  provide  a  statement  specifying  which  managed  object  classes  are  supported.  A  MOCS  i 
proforma  shall  be  completed  by  the  implementor  for  each  managed  object  class  supported.  ] 

Editor's  Note:  [The  CD  Version  of  ISO/IEC  10165-6  (Requirements  and  Guidelines  for  Implementation 
Conformance  Statement  Proformas  Associated  with  Management  Information)  is  now 
available.  MOCS  Proformas  for  each  managed  object  class  supported  should  be  developed 
consistent  with  10165-6  [MOCS].]  | 

I 

For  each  managed  object  class  supported,  the  following  shall  be  supplied:  I 

a)  a  statement  of  pragmatic  constraints  (e.g.,  attribute  values/ranges,  initial  values)  supported,  | 
unless  such  constraints  are  defined  in  the  managed  object  class  definition; 

b)  a  statement  of  conditional  packages  supported; 

c)  a  statement  of  role(s)  (manager,  agent,  or  both)  in  which  the  object  class  definition  is  j 
supported.  ! 

Editor's  Note:  [CD  10165-6  does  not  currently  distinguish  roles.] 


8.3.4       Management  Application  Contexts 

The  implementation  shall  support  at  least  the  application  context  for  systems  management  defined  in  ISO/IEC 
10040  [SMOj. 

Note:   [Such  a  statement  is  required  by  [SMO]  clause  7.2.] 

Note:   [Such  a  statement  is  required  by  part  5,  clause  1 3.7,  which  discusses  conformance  requirements 
for  these  lAs,  as  related  to  services  required  of  the  upper  layers  and  other  ASEs.] 


8.4       Demonstration  of  Conformance 

(Refer  to  the  Working  Implementation  Agreements  Document.) 


8.4.1        Management  Communication 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
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8.4.2  Management  Functions  and  Services 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

8.4.3  Management  Information 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
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Annex  A  (informative) 


Management  Information  Library  (MIL) 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  information.) 
A.1  Introduction 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
A.2  Rules  and  Procedures 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
A.3  General  Guidelines 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
A.4  Harmonized  Library 

The  definitions  specified  in  this  clause  can  be  referenced  by  using  the  label  "0P1  Library  Vol.  1"  (e.g.,  "0P1 
Library  Vol.  1":computerSystem). 

By  inclusion  of  the  managed  object  (MO)  definitions  and  the  object  identifiers  in  Annex  A  and  Annex  B, 
respectively,  of  the  Stable  Implementors'  Agreements  (SIAs),  these  managed  object  (MO)  definitions  have 
become  formally  registered.  Implementors  of  part  18  of  the  SIAs  do  not  have  to  support  any  of  these  MOs. 
However,  even  though  Annex  A  and  Annex  B  are  informative  annexes,  any  implementation  that  claims  to 
conform  to  these  definitions  must  treat  these  definitions  as  normative  and  comply  with  the  relevant  portions 
of  Annex  A.4  and  A.5,  and  Annex  B. 

A.4.1  Managed  Object  Classes  and  Mandatory  Packages 

A.4. 1.1  Computer  System 

computerSystem     MANAGED  OBJECT  CLASS 

DERIVED  FROM    "Rec.  X.721   j  ISO/IEC  10165-2  :  1992":top; 

CHARACTERIZED  BY  computerSystemPkg; 

CONDITIONAL  PACKAGES 

peripheralNamePkg  PRESENT  IF  !an  instance  supports  it  and  the 

peripheralListPkg  is  NOT  present!, 
peripheralListPkg  PRESENT  IF  !an  instance  supports  it  and  the 

peripheralNamePkg  is  NOT  present!, 
process ingEntityNamePkg    PRESENT  IF  !an  instance  supports  it  and  the 

processingEntityListPkg  is  NOT  present!, 
process i ngEnt i tyListPkg    PRESENT  IF  !an  instance  supports  it  and  the 

process ingEntityNamePkg  is  NOT  present!, 
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systemTimePkg  PRESENT  IF  !an  instance  supports  it!, 

upTimePkg  PRESENT  IF  !an  instance  supports  it!, 

"Rec.  M.3100  :  1992":userLabelPackage 

PRESENT  IF  !an  instance  supports  iti, 
usageStatePkg  PRESENT  IF  [resource  can  detect  usage!; 

REGISTERED  AS    Cx-obJectClass  1>; 


computerSystemPkg  PACKAGE 

BEHAVIOUR  computerSystemPkgDef inition, 
computerSystennPkgBehaviour; 

ATTRIBUTES 

computerSystemld  GET, 
"Rec.  X.721  !  ISO/IEC  10165-2 
"Rec.  X.721      ISO/IEC  10165-2 
"Rec.  X.721      ISO/IEC  10165-2 
"Rec.  X.721  I  ISO/IEC  10165-2 


1992": operational State  GET, 
1992":administrativeState  GET-REPLACE, 
1992":alarnoStatus  GET-REPLACE  ADD-REMOVE, 
1992":availabilityStatus  GET; 


ATTRIBUTE  GROUPS 
"Rec.  X.721  I 


ISO/IEC  10165-2  :  1992" 
"Rec.  X.721   !  ISO/IEC  10165-2  : 
X.721      ISO/IEC  10165-2  : 
X.721      ISO/IEC  10165-2  : 
X.721      ISO/IEC  10165-2  : 


"Rec 
"Rec 
"Rec 


:state 

1992":administrativeState 
1992":operationalState 
1992":alarmStatus 
1992":avai labi lityStatus; 


NOTIFICATIONS 

"Rec.  X.721  j  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 


1 992" : ob j  ec tCreat  i  on, 

1992":objectDeletion, 

1 992  " :  a  1 1  r  i  but  eVa  I  ueChange , 

1992":stateChange, 

1 992" : process  i  ngE  r rorA I arm, 

1 992 " : env  i  r onment  a  I A I  arm, 

1 992" : equ  i  pment A I a rm; ; 


computerSystemPkgDef  i  ni  t  i  on 


BEHAVIOUR 


DEFINED  AS 

!The  Computer  System  managed  object  class  represents  the  aggregate  of  components  which,  when 
considered  as  a  whole,  is  capable  of  performing  data  processing,  storage,  and  retrieval  functions. 
In  order  to  perform  its  function,  the  computer  system  may  have  a  variety  of  components  including 
processing  entities,  terminals,  disk  drives,  printers,  etc. 


The  Computer  System  is  intended  to  represent  an  aggregation  of  other  objects,  and  can  n»del  either 
self-contained  computer  systems  or  computer  systems  which  are  physically  distributed,  possibly  over 
a  wide  geographical  area.    An  instance  of  the  Computer  System  managed  object  class  may  have 
subordinate  managed  objects  representing  the  individual  entities  within  the  computer  system. 
Examples  are  entities  such  as  disks,  operating  systems  and  processing  entities. 

Since  the  Computer  System  may  be  physically  distributed,  it  is  not  appropriate  to  model  the  computer 
system  managed  object  class  as  a  subclass  of  the  Equipment  managed  object  class  (since  Equipment 
implies  a  single  physical  location  through  its  location  attribute).    However,  there  can  be  cases 
where  the  Computer  System  is  not  physically  distributed,  in  which  case  a  Name  Binding  allowing 
Computer  System  to  be  named  by  OMNIPoint  Equipment  is  permissible. 

It  is  not  appropriate  to  model  Computer  System  as  a  subclass  of  the  DMI  System  managed  object  class. 
Unlike  Computer  System,  the  DMI  System  is  a  "container"  object  class  which  is  instantiated  in 
managed  systems  and  exists  mainly  to  name  the  managed  and  support  objects  it  makes  visible. I; 


computerSystemPkgBehaviour  BEHAVIOUR 
DEFINED  AS 
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!A  value  for  the  computerSystemId  attribute  can  only  be  provided  when  the  object  is  created. 
Furthermore,  this  attribute  value  may  not  change  once  the  managed  object  has  been  instantiated. 
Thus,  this  attribute  is  never  the  subject  of  an  AttributeValueChange  Notification. 

Conditions  under  which  an  AttributeValueChange  Notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement  in  the  behaviour,  the 
attribute  does  not  cause  an  AttributeValueChange  notification  to  be  emitted. 
All  attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter. 

The  stateChange  notification  is  emitted  when  any  of  the  following  attributes  change  in  value: 
administrativeState,  operationalState,  and  availability  status. 

The  StateChange  notification  is  not  emitted  when  the  alarmStatus  attribute  changes  value.  (This  is 
to  avoid  duplication  of  notifications.) 

Since  every  combination  of  state  attribute  values  may  not  be  appropriate  for  particular  kinds  of 
computer  systems,  only  appropriate  combinations  need  be  supported. 

The  processingErrorAlarm  notification  is  emitted  when  the  computerSystem  resource  experiences  any  of 
the  alarm  conditions  defined  by  ISO/IEC  1016A-4  (e.g.,  storage  capacity  problem,  version  mismatch, 
corrupt  data,  software  error,  underlying  resource  unavai lable). ! ; 


A.4.1.2  Connection  Oriented  Transport  Protocol  Layer  Entity 


coTransportProtocolLayerEntity       MANAGED  OBJECT  CLASS 

DERIVED  fRW  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":top; 

CHARACTERIZED  BY  coTransportProtocolLayerEntityPkg; 


CONDITIONAL  PACKAGES 

manuf acturerL  i  stPkg 

manuf acturerNamePkg 

productLabelPkg 

opVersionPkg 

serialNumberPkg 

typeTextPkg 

upTimePkg 

incomingProtocolErrorPkg 
outgoingProtocolErrorPkg 
checksumPDUsD  i  scardedPkg 
maxPDUSizelVPkg 


usageStatePkg 
REGISTERED  AS  (x-objectClass  2>; 


PRESENT 

PRESENT 

PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 
Connect 
provide 
PRESENT 


IF  !an  instance  supports  it  and  the 

manufacturerNamePkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

manuf acturerL istPkg  is  NOT  present!, 
IF  !an  instance  supports  it!, 
IF  Ian  instance  supports  it!, 
!an  instance  supports  it!, 
!an  instance  supports  it!, 
!an  instance  supports  it!, 
IF  !an  instance  supports  it!, 
IF  !an  instance  supports  it!, 
IF  Ian  instance  supports  it!, 
IF  Ithe  "0P1  Library  Vol.  2  :  1992": transport 
ionlVMO  object  class  is  not  used  to 
this  initial  value!, 
IF  'resource  can  detect  usage!; 


IF 
IF 
IF 


coTransportProtocolLayerEnti tyPkg  PACKAGE 

BEHAVIOUR    CoTransportProtocolLayerEnti tyPkgDefinit ion, 
CoTransportProtocolLayerEnti tyPkgBehavi our; 

ATTRIBUTES 

coTransportProtocolLayerEntityld   PERMITTED  VALUES  SYNTAX- 1 .GraphicString64  GET, 

transportEnti tyType  GET, 

I oca  I  Transport Addresses  GET, 

act iveConnect ions    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
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maxConnecti 
"Rec.  X.721 
"Rec.  X.721 
"Rec.  X.721 
"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 

"Rec.  X.721 


ATTRIBUTE  GROUPS 
"Rec.  X.721 


ons     PERM I 
!  ISO/IEC 
ISO/IEC 
ISO/IEC 
I  ISO/IEC 


ISO/IEC 
ISO/IEC 
ISO/IEC 
ISO/IEC 
ISO/IEC 
ISO/IEC 
ISO/IEC 
ISO/IEC 
ISO/IEC 


TTED  VALUES  SYNTAX- 1 . Integer32  GET, 
10165-2  :  1992":aclministrativeState  GET-REPLACE, 
1992":operationalState  GET, 
1992":alarmStatus  GET-REPLACE  ADD-REMOVE, 
1 992" :  out  go  i  ngComec  t  i  onR  eques  t  sCoun  t  er 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" : i  ncomi  ngConnect  i  onRequestsCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1 992" : out go  i  ngConnec  t  i  onRe  j  ec  tE  rrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992": incomi ngConnect ionRejectErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992":outgoingDisconnectErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1 992" : i  ncomi  ngD  i  sconnectE  rrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" : i  ncomi  ngD  i  sconnectCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" : outgoi  ngD  i  sconnectCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992":octetsSentCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
1992" : octetsRecei  vedCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET; 


10165-2 
10165-2 
10165-2 

10165-2 

10165-2 

10165-2 

10165-2 

10165-2 

10165-2 

10165-2 

10165-2 

10165-2 


ISO/IEC  10165-2  :  1992":state 
Rec.  X.721  j  ISO/IEC  10165-2  :  1992":administrativeState 
Rec.  X.721      ISO/IEC  10165-2  :  1992": operational  State 
Rec.  X.721  j  ISO/IEC  10165-2  :  1992":alarmStatus; 


ACTIONS      activate,  deactivate; 


NOTIFICATIONS 
"Rec.  X.721 
"Rec 
"Rec 


X.721 
X.721 


"Rec.  X.721 
"Rec.  X.721 


ISO/IEC  10165- 

ISO/IEC  10165- 

ISO/IEC  10165- 

ISO/IEC  10165- 

ISO/IEC  10165- 


1992":objectCreation, 

1992" :objectDelet ion, 

1992" : at t  r  i  buteVa I ueChange, 

1992":stateChange, 

1 992" : process  i  ngE  r r or A I a  rm; ; 


coTransportProtocolLayerEntityPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!The  coTransportProtocolLayerEntity  managed  object  class  represents  an  instantiation   of  any 
connection-oriented  transport  layer  protocol  (e.g.,  the  ISO  Transport  Protocol      layer  or  the 
Internet  Transmission  Control  Protocol  (TCP)  Layer).    The  transport     protocol  layer  is  layer  four 
of  the  OSI  Reference  model.    It  provides  for  the     transparent  transference  of  data  between  two  peer 
entities.    It  relieves  its  users     from  any  concerns  about  the  detailed  way  in  which  supporting 
communication  media  are     utilized  to  achieve  this  transfer.    The  connection-oriented  transport 
protocol  layer     entity  makes  use  of  a  transport  connection  for  the  purpose  of  transferring  data. 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connect  ion- oriented  transport  protocol  -  rather  it  contains  characteristics  conmon  across  various 
different  connection-oriented  transport  layer  protocols.    This  managed  object  class  is  not  intended 
to  override  any  transport  layer  managed  object  classes  defined  in  ISO.    It  provides  a  high  level 
view  of  a  connect  ion- oriented  transport  layer  protocol  and  complements  the  protocol-specific  views 
being  defined  in  the  standards.!; 


coTransportProtocolLayerEntityPkgBehaviour  BEHAVIOUR 
DEFINED  AS 
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IConditions  under  which  an  attributeValueChange  notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.  In  the  absence  of  such  a  statement,  in  the  behaviour,  the 
attribute  does  not  cause  an  attributeValueChange  to  Be  emitted. 

The  attributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  localTransportAddresses,  maxConnections,  transportEntityType,  and  all  counter  attributes 
(only  when  they  wrap).    All  attributeValueChange  notifications  shall  include  the  Attribute 
Identifier  List  parameter.    All  attributeValueChange  notifications  which  report  counter  attribute 
wraps  shall  contain  the  maximum  counter  attribute  value  in  the  Old  Attribute  Value  parameter. 

The  stateChange  notification  is  emitted  when  any  of  the  following  attributes  change  in  value: 
administrati veState  and  operational  State. 

The  processingErrorAlarm  notification  is  emitted  when  the  coTransportProtocolLayerEntity  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem, 
version  mismatch,  corrupt  data,  software  error,  underlying  resource  unavailable).!; 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific  connection- 
oriented  transport  protocol.    ISO/IEC  10733  [TLM]  defines  specific  objects  for  managing  OSI  transport 
protocol  layer  entities. 


A.4.1.3  Connectionless  Network  Protocol  Layer  Entity 


clNetworkProtocolLayerEntity       MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  X.721   j  ISO/IEC  10165-2  :  1992":  top; 

CHARACTERIZED  BY    clNetworkProtocolLayerEnti tyPkg; 


CONDITIONAL  PACKAGES 


manuf acturerL  i  stPkg 

manufacturerNamePkg 

productLabelPkg 

opVersionPkg 

serialNumberPkg 

typeTextPkg 

upTimePkg 


PRESENT  IF  !an  instance  supports  it  and  the 

manufacturerNamePkg  is  NOT  present!, 
PRESENT  IF  !an  instance  supports  it  and  the 

manufacturerListPkg  is  NOT  present!, 
PRESENT  IF  Ian  instance  supports  it!, 
PRESENT  IF  Ian  instance  supports  it!, 
PRESENT  IF  Ian  instance  supports  it!, 
PRESENT  IF  Ian  instance  supports  it!, 
PRESENT  IF  Ian  instance  supports  it!; 


REGISTERED  AS    Cx-objectClass  3}; 


c I NetworkProtocol LayerEnt  i  tyPkg  PACKAGE 


BEHAVIOUR    c I NetworkProtocol LayerEnt  i  tyPkgDef  i  ni  t  i  on, 
c INetworkProtocol LayerEnt  i  tyPkgBehavi  our; 


ATTRIBUTES 

clNetworkProtocolLayerEntityld  PERMITTED  VALUES  SYNTAX- 1 .GraphicString64  GET, 
networkEnti tyType  GET, 

localNetworkAddresses    GET-REPLACE  ADD-REMOVE, 

nPDUTimeToLive    PERMITTED  VALUES  SYNTAX-1 . Integer32  GET-REPLACE, 

"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":administrativeState  GET-REPLACE, 

"Rec.  X.721      ISO/IEC  10165-2  :  1992":operationalState  GET, 

"Rec.  X.721      ISO/IEC  10165-2  :  1992":alarmStatus    GET-REPLACE  ADD-REMOVE, 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":pdusSentCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":pdusRecei vedCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":octetsSentCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
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"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":octetsReceivedCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
pdusForwardedCounter    PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
pdusReasnbldOKCounter    PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
pdusReasmbldFai ICounter    PERMITTED  VALUES  SYNTAX-1. I nteger32  GET, 
pdusDiscardedCounter     PERMITTED  VALUES  SYNTAX-1. I nteger32  GET; 

ATTRIBUTE  GROUPS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":state 

"Rec.  X.721  {  ISO/IEC  10165-2  :  1992":administrativeState 
"Rec.  X.721      ISO/IEC  10165-2  :  1992":operationalState 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":alarmStatus; 


ACTIONS       activate,  deactivate; 

NOTIFICATIONS 

"Rec.  X.721  !  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  I  ISO/IEC  10165-2 


1992" :objectCreat ion, 
1992":objectDeletion, 
1992":attributeValueChange, 
1 992" : process  i  ngE  rrorA I  arm, 
1 992 " :  c omiKin  i  ca  t  i  ons A I  a  rm , 
1992":stateChange;; 


clNetworkProtocolLayerEntityPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!The  clNetworkProtocolLayerEntity  managed  object  class  represents  an  instantiation  of  a 
connectionless  network  protocol  layer.    The  network  protocol  layer  provides  network  services  for  the 
transparent  transfer  of  data  between  peer  transport  entities.    It  relieves  the  transport  protocol 
layer  from  the  need  to  know  anything  about  the  underlying  network  technologies  used  to  achieve  data 
transfer. 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connectionless  network  protocol;  instead,  it  contains  characteristics  common  across  various 
different  connectionless  network  layer  protocols.    This  managed  object  class  is  not  intended  to 
override  any  network  layer  managed  object  classes  defined  in  ISO.    It  provides  a  high  level  view  of 
a  connectionless  network  layer  protocol  and  complements  the  protocol -specific  views    being  defined 
in  the  standards. 

An  instance  of  this  managed  object  class  supports  only  one  type  of  protocol.!; 
clNetworkProtocolLayerEntityPkgBehaviour  BEHAVIOUR 
J)EFINED  AS 

{Conditions  under  which  an  attributeValueChange  notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.  In  the  absence  of  such  a  statement,  in  the  behaviour,  the 
attribute  does  not  cause  an  attributeValueChange  to  be  emitted. 

The  attributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  networkEntityType,  localNetworkAddresses,  nPDUTimeToLive,  and  all  counter  attributes  (only 
when  they  wrap).    All  attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List 
parameter.    All  attributeValueChange  notifications  which  report  counter  attribute  wraps  shall 
contain  the  maxinxjm  counter  attribute  value  in  the  Old  Attribute  Value  parameter. 

The  stateChange  notification  is  emitted  when  any  of  the  following  attributes  change  in  value: 
administrati veState  and  operationalState. 

The  communicationsAlarm  notification  is  emitted  when  the  clNetworkProtocolLayerEntity  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  loss  of  signal,  local 
transmission  error,  remote  transmission  error).    In  particular,  this  notification  is  used  to  report 
when  a  data  NPDU  is  discarded  for  any  reason  other  than  network  congestion. 
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The  processingErrorAlarm  notification  is  emitted  when  the  clNetworkProtocolLayerEntity  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem, 
version  mismatch,  corrupt  data,  software  error,  underlying  resource  unavailable).!; 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connectionless  network  protocol.    ISO/IEC  10737  [NLM]  defines  specific  objects  for  managing  OS!  network 
protocol  layer  entities. 

A.4.1.4  OMNIPoint  Equipment 

This  definition  is  subclassed  from  CCITT  M.3100  Equipment,  adding  the  following  items: 

Mandatory  AttributeChange,  ObjectCreation,  ObjectOeletion  Notifications 
Mandatory  Environmental,  Processing  Error,  and  Equipment  Alarm  Notifications 
Mandatory  Administrative  and  Operational  State  Attributes  and  State  Change  Notification 
CREATE/DELETE  operations  and  behaviours  (in  name  bindings) 

Conditional  Contact,  Customer,  Function,  Manufacturer,  OMNIPoint  Network,  Service,  Software 

and  Vendor  Name  and  List  Packages 

Conditional  Product  and  Serial  Number  Packages 

Conditional  Type  Text  Package 

Conditional  Location  Pointer  Package 

--  ANSI  T1M1.5  concerns  regarding  physical  vs.  functional  modelling  were  resolved  by  excluding  the  Forum 
--  R1  Equipment  Type  attribute  from  the  OMNIPoint  definition.    The  TypeText,  FunctionName,  and/or 

FunctionList  attributes  may  be  used  to  carry  (as  graphic  strings  or  pointers)  information  concerning 
--  the  function(s)  supported  by  the  physical  Equipment.    It  is  expected  that  Forum  R1  to  OMNIPoint  1 

mapping  rules  will  define  a  translation  between  Forum  R1  EquipmentType  enumerations  and  these  OMNIPoint 
--  Equipment  attributes. 


opEquipment  MANAGED  OBJECT  CLASS 


!an  instance  supports  it  and  the 

contactNamePkg  is  NOT  present!, 
!an  instance  supports  it  and  the 

contactListPkg  is  NOT  present!, 
!an  instance  supports  it  and  the 

customerNamePkg  is  NOT  present!, 
!an  instance  supports  it  and  the 

customerListPkg  is  NOT  present", 
!an  instance  supports  it  and  the 

functionNamePkg  is  NOT  present!, 
■an  instance  supports  it  and  the 

functionListPkg  is  NOT  present!, 
!an  instance  supports  it  and  the 

"Rec.  M.3100  :  1992": 

locationNamePackage  is  NOT  present!, 
!an  instance  supports  it  and  the 

manufacturerNamePkg  is  NOT  present!, 
!an  instance  supports  it  and  the 


DERIVED  FROM    "Rec.  M.3100  :  1 992": equipment ; 

CHARACTERIZED  BY 

opEquipmentPkg, 

"Rec.  M.3100  :  1992":createDeleteNotif icationsPackage, 

.   "Rec.  M.3100  :  1992":attributeValueChangeNotif icationPackage, 

"Rec.  M.3100  :  1992":stateChangeNotif icationPackage, 

"Rec.  M.3100  :  1992":administrativeOperationalStatesPackage, 

"Rec.  M.3100  :  1992":envi ronmentalAlarmPackage, 

"Rec.  M.3100  :  1992":processingErrorAlarmPackage, 

"Rec.  M.3100  :  1992":equipmentsEquipmentAlarmPackage; 

CONDITIONAL  PACKAGES 


contactListPkg 

PRESENT 

IF 

contactNamePkg 

PRESENT 

IF 

customerListPkg 

PRESENT 

IF 

customerNamePkg 

PRESENT 

IF 

functionListPkg 

PRESENT 

IF 

functionNamePkg 

PRESENT 

IF 

locat  i  onPoi  nterPkg 

PRESENT 

IF 

manuf acturerL  i  stPkg 

PRESENT 

IF 

manufacturerNamePkg 

PRESENT 

IF 
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opNetworkListPkg 

PRESENT 

opNetworkNamePkg 

PRESENT 

opVersionPkg 

PRESENT 

productLabelPkg 

PRESENT 

serialNumberPkg 

PRESENT 

serviceListPkg 

PRESENT 

serviceNamePkg 

PRESENT 

sof twareListPkg 

PRESENT 

sof twareNamePkg 

PRESENT 

typeTextPkg 

PRESENT 

usageStatePkg 

PRESENT 

vendorListPkg 

PRESENT 

REGISTERED  AS    {x-objectClass  4}; 


manufacturerListPkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

opNetworkNamePkg  is  NOT  present!, 
IF  Ian  instance  supports  it  and  the 

OpNetworkListPkg  is  NOT  present!, 
IF  l''Rec.  M.3100  :  1992": 

versionPackage  is  also  present!, 
IF  !an  instance  supports  iti, 
IF  !an  instance  supports  it!, 
IF  !an  instance  supports  it  and  the 

serviceNamePkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

serviceListPkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

sof twareNamePkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

sof twareListPkg  is  NOT  present!, 
IF  !an  instance  supports  it!, 
IF  ! resource  can  detect  usage!, 
IF  !an  instance  supports  it  and  the 

"Rec.  M.3100  :  1992": 

vendorNamePackage  is  NOT  present!; 


opEquipmentPkg  PACKAGE 

BEHAVIOUR  opEquipmentPkgBehaviour; 

--    opEquipmentPkgDef inition  inherited  from  Rec.  M.3100  Equipment 

ATTRIBUTES 

"Rec.  M.3100  :  1992":equipmentld  PERMITTED  VALUES  SYNTAX-1 .EquipmentldRange  GET; 

ATTRIBUTE  GROUPS 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":state 

"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":administrativeState 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":operationalState; ; 


OpEquipmentPkgBehaviour  BEHAVIOUR 

DEFINED  AS  --  inherited  from  Rec.  M.3100  Equipment,  with  the  following  extensions: 

!A  value  for  the  "Rec.  M.3100  :  1992":equipmentld  attribute  can  only  be  provided  when  the  object  is 
created.    Furthermore,  this  attribute  value  may  not  change  once  the  managed  object  has  been 
instantiated.    Thus,  this  attribute  is  never  the  subject  of  an  AttributeValueChange  Notification. 

Conditions  under    which  an  AttributeValueChange  Notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement  in  the  behaviour,  the 
attribute  does  not  cause  an  AttributeValueChange  notification  to  be  emitted. 
All  attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter. 

The  process ingErrorA I arm  notification  (if  present)  is  emitted  when  the  Equipment  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem, 
version  mismatch,  corrupt  data,  software  error,  underlying  resource  unavailable).!; 

A.4.1.5  OMNIPoint  Network 

--  This  definition  is  subclassed  from  Rec.  M.3100  Network,  adding  the  following  items: 

Network  Title  and  associated  name  binding  to  Root 
AttributeChange,  ObjectCreation,  ObjectDeletion  Notifications 
CREATE/DELETE  operations  and  behaviours  (in  name  bindings) 
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opNetHork  MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  M.3100  :  1992" : network; 
CHARACTERIZED  BY  opNetworkPkg; 

REGISTERED  AS    Cx-objectClass  5>; 


opNetworkPkg  PACKAGE 

BEHAVIOUR  opNetworkPkgBehaviour; 

--  opNetworkPkgDef inition  inherited  from  Rec.  M.3100  Network 

ATTRIBUTES 

networkTitle  GET; 

NOTIFICATIONS 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":objectCreation, 

"Rec.  X.721      ISO/IEC  10165-2  :  1992":objectDeletion, 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":attributeValueChange;; 


opNetworkPkgBehaviour  BEHAVIOUR 

DEFINED  AS  --  inherited  from  Rec.  M.3100  Network,  with  the  following  extensions: 

■Values  for  the  Network  Identifier  and  Network  Title  attributes  can  only  be  provided  when  the  object 
is  created.    Furthermore,  these  attribute  values  may  not  change  once  the  managed  object  has  been 
instantiated.    Thus,  they  are  never  the  subject  of  an  AttributeValueChange  Notification.  When 
NetworkTitle  is  used  for  naming,  the  Network  Identifier  attribute  has  a  NULL  value. 

Conditions  under  which  an  AttributeValueChange  Notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement  in  the  behaviour,  the 
attribute  does  not  cause  an  AttributeValueChange  notification  to  be  emitted.  All 
attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter.!; 


A.4.1.6  Processing  Entity 

process ingEntity  MANAGED  OBJECT  CLASS 

DERIVED  FROM  opEquipment; 

CHARACTERIZED  BY    process ingEntityPkg; 

CONDITIONAL  PACKAGES 

addressingPkg  PRESENT  IF  ! relevant  to  the  underlying  resource!, 

cpuUtilizationPkg       PRESENT  IF  !an  instance  supports  it!, 

memorySizePkg  PRESENT  IF  ! relevant  to  the  underlying  resource!, 

memoryUti I izationPkg  PRESENT  IF  !an  instance  supports  it!, 

upTimePkg  PRESENT  IF  !an  instance  supports  it!; 

REGISTERED  AS    Cx-objectClass  6>; 

process ingEntityPkg  PACKAGE 

BEHAVIOUR  processingEntityPkgDef inition, 
processi  ngEnt  i  tyPkgBehavi  our; 

ATTRIBUTES 

cpuType  PERMITTED  VALUES  SYNTAX- 1 .GraphicStringId  GET, 

oslnfo  PERMITTED  VALUES  SYNTAX-1 .OsInfoRange  GET;; 
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process  i  ngEnt  i  tyPkgDef  i  ni  t  i  on  BEHAV I OUR 

DEFINED  AS 

!The  process! ngEnt ity  managed  object  class  represents  the  physical  portion  of  the  cotrputer  system 
that    performs  a  processing  function,  frequently  called  a  Central  Processing  Unit  (CPU).  A 
Processing  Entity  may  be  composed  of  such  components  as  arithmetical  logical  units  (ALU), 
registers  for  processing  memory,  limited  storage  most  often  in  the  form  of  Random  Access  Memory 
(RAM),  and  various    other  types  of  memory  used  in  the  processing  function.    It  does  not  include  such 
components  as  disk  drives,  data  bases,  etc. 

Some  Processing  Entities  may  have  input/output  channels,    particularly  when  hardware  is  shared 
between  elements    of  the  Processing  Entity.    In  other  cases,  the  input/output    must  be  seen  as 
components  of  a  superior  managed  object,  for    example  a  Computer  System,  or  as  OMNIPoint  Equipment 
objects  shared  among  several  Computer  Systems. 

The  cpuType  attribute  indicates  the  type  of  central  processor  unit  found  in  the  Processing  Entity. 

The  OS Info  attribute  specifies  the  names  and  releases  of  the  supported  operating  systems.!; 
process  i  ngEnt  i  tyPkgBeha  v  i  our  BEHAV  I CXJR 

DEFINED  AS 

■The  AttributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  cpuType  or  oslnfo.!; 


A.4.1.7  Transport  Connection 

transportConnection  MANAGED  OBJECT  CLASS 

DERIVED  FROM    "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  top; 

CHARACTERIZED  BY  transportConnectionPkg; 

CONDITIONAL  PACKAGES 

maxRet r ansmi ss i onsPkg 
ret ransmi  ss  i  onT  i  mePkg 
ret  ransmi  ss  i  onT  i  mer I ni  t  i  a  I Va luePkg 
pdusRetransmi  ttedCounterPkg 
octetsRetransmi  ttedPkg 
pdusRetransmi  ttedThresholdPkg 
outgoingProtocolErrorPkg 
checksumPDUsD  i  scardedPkg 

REGISTERED  AS  <x-objectClass  7>; 


transportConnectionPkg  PACKAGE 

BE  HAV I OUR    t  r anspor t Connec  t  i  onPkgDef  i  ni  t  i  on , 
t ransportConnect  i  onPkgBehavi  our; 

ATTRIBUTES 

transportConnectionId    PERMITTED  VALUES  SYNTAX-1 .GraphicString64  GET, 
I oca  I T  ranspor  t Connec  t  i  onEndpo  i  nt  GE T , 
remoteT ranspor tConnec t  i  onEndpo i  nt  GET , 

transportConnectionReference    PERMITTED  VALUES  SYNTAX- 1. I nteger32  GET, 
localNetworkAddress  GET, 
remoteNetworkAddress  GET, 

inactivityTimeout    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
inactivityTime  PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
maxPDUSize    PERMITTED  VALUES  SYNTAX- 1.1 nteger32  GET, 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":pdusSentCounter 


PRESENT  IF 
PRESENT  IF 
PRESENT  IF 
PRESENT  IF 
PRESENT  IF 
PRESENT  IF 
PRESENT  IF 
PRESENT  IF 


!an  instance 

San  instance 

!an  instance 

!an  instance 

!an  instance 

■an  instance 

!an  instance 

■an  instance 


supports  it 
supports  it 
supports  it 
supports  it 
supports  it 
supports  it 
supports  it 
supports  it 
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PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 

"Rec. 

X. 

.721  j 

;  ISO/IEC 

10165- 

•2  : 

1 992" : pdusRece  i  vedCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 

"Rec. 

X, 

.721  1 

1  ISO/IEC 

10165- 

■2  : 

1992":octetsSentCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 

"Rec. 

X, 

.721 

1  ISO/IEC 

10165- 

■2  : 

1992" :octetsRecet vedCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 

"Rec. 

X. 

.721 

1  ISO/IEC 

10165- 

■2  : 

1 992" : i  ncomi  ngProtoco I E  rrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 

NOTIFICATIONS 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":objectCreation, 

"Rec.  X.721  ISO/IEC  10165-2  :  1992":objectDeletion  transportOisconnectCause, 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":attributeValueChange;; 


transportConnectionPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!The  transportConnection  managed  object  class  represents  an  active  transport  connection  (e.g.,  an 
OSI  transport  connection  or  a  TCP  connection).    A  transport  connection  is  established  and  used  by 
two  peer  connection  oriented  transport  protocol  layer  entities  for  the  purpose  of  transferring  data. 
A  connection  oriented  transport  protocol  layer  entity  may  support  multiple  transport  connections. 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connection-oriented  transport  protocol;  rather  it  contains  characteristics  conmon  across  various 
different  connection-oriented  transport  layer  protocols.    This  managed  object  class  is  not  intended 
to  override  any  transport  layer  managed  object  classes  defined  in  ISO.    It  provides  a  high  level 
view  of  a  connection-oriented  transport  layer  protocol  and  complements  the  protocol -specific  views 
being  defined  in  the  standards.!; 


transportConnectionPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!An  instance  of  the  Transport  Connection  managed  object  class  is  created  automatically  in  response 
to  normal  operation  of  the  network.    A  prerequisite  to  the  creation  of  a  transport  connection  is  the 
existence  of  a  transport  entity  (e.g.  an  instance  of  the  Connection  Oriented  Transport  Protocol 
Layer  Entity)  on  the  open  system.  When  a  new  Transport  Connection  instance  is  created,  the  "0P1 
Library  Vol.  2  :  1992":transportConnectionIVM0  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance.    Alternatively,  the  Maximum  PDU  Size 
attribute  takes  on  the  value  of  the  Maximum  PDU  Size  attribute  specified  in  the  superior  Transport 
Protocol  Layer  Entity  managed  object  instance.  Subsequently  the  Maximum  PDU  Size  attribute  may  take 
on  another  value  which  applies  specifically  to  the  connection  represented  by  the  instantiation  of 
the  transport  connection.    This  change  may  occur  as  the  result  of  peer  protocol  negotiation. 

The  Additional  Information  parameter  of  the  objectDeletion  notification  may  optionally  contain  a 
management  extension  (as  defined  in  DMI)  whose  identifier  is  that  of  the  "cause"  attribute,  whose 
significance  is  FALSE,  and  whose  information  is  "cause"  as  defined  in  the  associated  PARAMETER 
template. 

Conditions  under  which  an  attributeValueChange  notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement,  in  the  behaviour,  the 
attribute  does  not  cause  an  attributeValueChange  to  be  emitted. 

The  attributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  inactivityTimeout,  maxPDUSize,  and  all  counter  attributes  (only  when  they  wrap).  All 
attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter.  All 
attributeValueChange  notifications  which  report  counter  attribute  wraps  shall  contain  the  maximum 
counter  attribute  value  in  the  Old  Attribute  Value  parameter. 

Transport  Connection  will  delete  itself  when  the  value  of  the  inactivityTime  attribute  equals  that 
of  the  inactivityTimeout  attribute.!; 
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This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific  connection- 
oriented  transport  protocol.    ISO/IEC  10733  [TLM]  defines  specific  objects  for  managing  OSI  transport 
protocol  layer  entities. 

A.4.2  Conditional  Packages 


A.4.2.1  Addressing  Package 

address ingPkg  PACKAGE 

BEHAVIOUR      address i  ngPkgDef  i  ni  t  i  on, 
address  i  ngPkgBehav  i  our ; 

ATTRIBUTES     address ingSize     PERMITTED  VALUES  SYNTAX- 1 .Address ingSizeRange  GET, 
endianess  GET; 
REGISTERED  AS  {x-package  1>; 

addressingPkgDef inition  BEHAVIOUR 

DEFINED  AS 

'This  package  defines  the  addressing  size  and  endianess  which  are  characteristic  of  the  underlying 
resource.!; 

addressingPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

I  If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  address ingSize  or  endianess  attributes  change 
value. I ; 

A.4.2.2  Checksum  PDUs  Discarded  Package 

checksumPDUsDiscardedPkg  PACKAGE 

BEHAVIOUR    checksumPDUsD  i  scardedPkgDef  i  ni  t  i  on, 
checksumPDUsD  i  scardedPkgBehav  i  our ; 

ATTRIBUTES 

ChecksumPDUsD iscardedCounter  PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 
REGISTERED  AS    (x-package  2>; 


ChecksumPDUsD  i  scardedPkgDef  i  ni  t  i  on   BE  HAV I OUR 
DEFINED  AS 

!This  package  reflects  the  capability  of  the  underlying  resource  to  count  the  number  of  well-formed 
PDUs  rejected  by  the  peer  entity  due  to  a  checksum  error,!; 


ChecksumPDUsD iscardedPkgBehavi our  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  checksumPDUsD i scarded  attribute  wraps.!; 


A.4.2.3  Contact  List  Package 

contactListPkg  PACKAGE 
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BEHAVIOUR  contactListPkgDefinition, 
contactL i stPkgBehavi our; 

ATTRIBUTES     contactList    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange    GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  {x-package  3>; 


contactListPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!The  Contact  List  Attribute  identifies  who  (person  or  organization)  should  be  contacted  about  the 
resource. I ; 

contactListPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

nf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  contactList  attribute  changes  value. I; 

A.4.2.4  Contact  Name  Package 

contactNamePkg  PACKAGE 

BEHAVIOUR  contactNamePkgDef inition, 
cont ac  tNamePkgBehav  i  our ; 

ATTRIBUTES     contactName    PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  <x-package  4>; 


ContactNamePkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThe  Contact  Name  Attribute  identifies  who  (person  or  organization)  should  be  contacted  about  the 
resource. I ; 

contactNamePkgBehaviour  BEHAVIOUR 

DEFINED  AS 

I  If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  contactName  attribute  changes  value.!; 

A.4.2.5  CPU  Utilization  Package 

cpuUtilizationPkg  PACKAGE 
BEHAVIOUR  cpuUtilizationPkgBehaviour; 

ATTRIBUTES     cpUUti lization     PERMITTED  VALUES  SYNTAX-1 .PercentageRange 

GET;  --    changed  from  GET -REPLACE  (Forum) 

REGISTERED  AS  (x- package  5>; 
cpuUtilizationPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

lEven  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  NOT  emitted  when  the  cpuUt i I i zat i on  attribute  changes  value.!; 

A.4.2.6  Customer  List  Package 
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customerListPkg  PACKAGE 

BEHAVIOUR  customerListPkgDef inition, 
customerListPkgBehaviour; 

ATTRIBUTES    customerList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  <x-package  6>; 

customerL i stPkgDef i ni  t i on   BEHAVI OUR 

DEFINED  AS 

•The  Customer  List  attribute  identifies  any  customers  that    are  users  of  the  resource. I, • 
customerListPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  customerList  attribute  changes  value.!; 

A.4.2.7  Customer  Name  Package 

customerNamePkg  PACKAGE 

BEHAVIOUR  customerNamePkgOef inition, 
cus  t omerNamePkgBehav  i  our ; 

ATTRIBUTES    customerName  PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  {x-package  7>; 

customerNamePkgDef inition  BEHAVIOUR 

DEFINED  AS 

!The  Customer  Name  attribute  identifies  any  customer  that  is  a  user  of  the  resource.!; 
customerNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  customerName  attribute  changes  value.!; 

A.4.2.8  Function  List  Pacl(age 

functionListPkg  PACKAGE 

BEHAVIOUR  functionLi StPkgDef inition, 
f unc t i onL i s t PkgBehav i our ; 

ATTRIBUTES  functionList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  €x- package  8>; 

functionListPkgDef inition  BEHAVIOUR 

DEFINED  AS 

!The  functionList  attribute  identifies  those  functions    provided  by  this  resource.!; 
f unct  i  onL  i  stPkgBehavi  our    BEHAVI OUR 
DEFINED  AS 
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ilf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  functionList  attribute  changes  value.!; 

A.4.2.9  Function  Name  Package 

functionNamePkg  PACKAGE 

BEHAVIOUR  functionNamePkgDef inition, 
f unc t i onNamePkgBehav i our ; 

ATTRIBUTES  functionName  PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  Cx-package  9>; 

functionNamePkgDef inition  BEHAVIOUR 

DEFINED  AS 

■The  functionName  attribute  identifies  the  function  provided  by  this  resource. I; 
functionNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

Ilf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  functionName  attribute  changes  value.!; 

A.4.2.10  Incoming  Protocol  Error  Package 

incomingProtocolErrorPkg  PACKAGE 

BEHAVIOUR    incomingProtocolErrorPkgDef inition, 
i ncomi ngProtocol ErrorPkgBehavi our; 

ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992": incomingProtocolErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 

REGISTERED  AS    <x-package  10}; 


i  ncomi  ngProtoco I E  r rorPkgDef  i  n  i  t  i  on   BE  HAV I OUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  resource  to  count  the  nurber  of  incoming 
protocol  errors  detected.!; 


incomingProtocolErrorPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  incomingProtocolErrorCounter  attribute  wraps.!; 

A.4.2.11  Location  Pointer  Package 

locationPointerPkg  PACKAGE 

BEHAVIOUR      locationPointerPkgDef inition, 
I ocat  i  onPo  i  nterPkgBehavi  our; 

ATTRIBUTES 

locationPointer  GET-REPLACE; 
REGISTERED  AS         {x-package  11); 
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locat i onPoi nterPkgDef  i ni  t i on  BEHAVIOUR 
DEFINED  AS 

!This  package  provides  managed  object  instance  information  for  a  location  (e.g.,  Hilo  Hawaii  USA).!; 


locat ionPointerPkgBehavi our  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Location  Pointer  attribute  changes  value. I; 


A.4.2.12  Manufacturer  List  Package 

tnanufacturerListPkg  PACKAGE 

BEHAVI OUR     manuf acturerL  i  stPkgOef  i  ni  t  i  on, 
manuf acturerL  i  stPkgBehavi  our  ; 

ATTRIBUTES 

manufacturerList    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REHOVE; 
REGISTERED  AS         Cx-package  12}; 


manuf acturerL  i  stPkgDef  i  ni  t  i  on  BEHAV I  OUR 
DEFINED  AS 

IThis  package  indicates  information  about  the  manufacturer(s)  that  manufactured  the  underlying 
resource! ; 


manuf acturerL  i  stPkgBehavi  our  BEHAVI OUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  ManufacturerList  attribute  changes  value.!; 


A.4.2.13  Manufacturer  Name  Package 

manufacturerNamePkg  PACKAGE 

BEHAVIOUR     manufacturerNamePkgDef inition, 
manuf acturerNamePkgBehavi our; 

ATTRIBUTES 

manuf acturerName    PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 
REGISTERED  AS  Cx-package  13>; 


manufacturerNamePkgDef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  indicates  information  about  the  manufacturer  that  manufactured  the  underlying 
resource! ; 

manuf acturerNamePkgBehavi our  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  ManufacturerName  attribute  changes  value.!; 
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A.4.2.14  Max  PDU  Size  IV  Package 


maxPOUSizelVPkg  PACKAGE 

BEHAVIOUR     maxPDUSi  zel VPkgDef  i  ni  t  ion, 
maxPDUS  i  ze I VPkgBehavi  our ; 

ATTRIBUTES 

maxPDUSize    PERMITTED  VALUES  SYNTAX-1 . Integer32  GET-REPLACE; 
REGISTERED  AS  {x-package  U>; 


maxPDUSizelVPkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  provides  the  initial  value  for  the  maximum  length  of  a  PDU  that  can  be  supported  by 
the  local  layer  entity.!; 

maxPDUSizelVPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

■The  Maximum  TPDU  Size  attribute  provides  the  initial  value  to  be  used  by  newly- instantiated 
subordinate  Transport  Connection  managed  object  instances  for  the  maximum  TPDU  size  to  be  supported 
on  that  connection.!; 


A.4.2.15  Max  Retransmissions  Package 


maxRetransmissionsPkg  PACKAGE 

BEHAVIOUR    maxRet ransmi  ss  i  onsPkgDef  i  ni  t  i  on, 
maxRet  ransmi  ss  i  onsPkgSehavi  our; 

ATTRIBUTES 

maxRet ransmi ss ions    PERMITTED  VALUES  SYNTAX-1 . Integer32  GET; 
REGISTERED  AS    <x-package  15}; 


maxRetransmissionsPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  count  the 
maximum  number  of  times  a  TPDU  is  to  be  retransmitted  before  the  transport  connection  is  aborted.!; 


maxRetransmissionsPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

■When  a  new  Transport  Connection  instance  is  created  containing  this  package,  any  "OPI  Library  Vol. 
2  :  1992":transportConnectionRetransmissionIVM0  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance.!; 

A.4.2.16  Memory  Size  Package 

memorySizePkg  PACKAGE 

BEHAVIOUR  memorySizePkgDef inition, 

memorySizePkgBehaviour; 
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ATTRIBUTES     menwryS i ze     PERMITTED  VALUES  SYNTAX - 1 .MemorySizeRange  GET; 
REGISTERED  AS  (x-package  16>; 
memorySizePkgDef inition  BEHAVIOUR 
DEFINED  AS 

!The  memorySize  attribute  indicates,  in  kilobytes,  the  amount  of  memory  available  to  a  Processinfl 
Entity  (irrespective  of  its  current  usage).!; 

memorySizePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!lf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  memorySize  attribute  changes  value.!; 

A.4.2.17  Memory  Utilization  Package 

memoryUt  i I i  zat  i  onPkg  PACKAGE 
BEHAVIOUR      memoryUti I izationPkgBehaviour; 

ATTRIBUTES     memoryUt i I i zat i on     PERMITTED  VALUES  SYNTAX-1 .PercentageRange 

GET;        added  in  response  to  Bull  conment 

REGISTERED  AS  Cx-package  17>; 

memoryUti I izationPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

■Even  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  NOT  emitted  when  the  memoryUti I izati on  attribute  changes  value.!; 

A.4.2.18  Octets  Retransmitted  Package 

octetsRetransmittedPkg  PACKAGE 

BEHAVIOUR    octetsRetransmittedPkgDef inition, 
octetsRetransmittedPkgBehaviour; 

ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":octetsRetransmittedErrorCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET; 

REGISTERED  AS    {x-package  18>; 


octetsRet  ransmi  1 1 edPkgDef  i  n  i  t  i  on   BE  HAV I OUR 
DEFINED  AS 

!This  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  count  the 
number  of  octets  retransmitted.!; 


octetsRet  ransmi  t tedPkgBehav  i  our   BEHAV I OUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  octetsRetransmitted  attribute  wraps.!; 
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A.4.2.19  OMNiPoint  Network  List  Package 

opNetHorkListPkg  PACKAGE 

BEHAVIOUR  opNetworkL  i  stPkgDef  i nt  t  i on, 
opNetworkL i stPkgBehavi our; 

ATTRIBUTES    opNetuorkList    PERNITTED  VALUES  SYNTAX- t .AnyNamesRange  GET-REPLACE  AOD-REMOVE; 

REGISTERED  AS  <x-package  19>; 

opNetworkL  i  s tPkgOef  i  ni  t  i  on   BEHAV I OUR 

DEFINED  AS 

iThe  opNetworkList  attribute  indicates  what  networks  use  or  are  dependent  on  the  resource.!; 
opNetworkL  i  stPkgBehavi  our    BE  HAV I OUR 
DEFINED  AS 

I  If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  opNetworkList  attribute  changes  value.!; 

A.4.2.20  OMNIPoint  Network  Name  Package 

opNetworkNamePkg  PACKAGE 

BEHAVIOUR  opNetworkNamePkgDefinition, 
o|3NetworkNamePkgBehavi  our; 

ATTRIBUTES    opNetworkName    PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  <x-package  20>; 

opNetworkNamePkgDef  i  ni  t  i  on   BEHAV I OUR 

DEFINED  AS 

IThe  opNetworkName  attribute  indicates  what  network  uses  or  is  dependent  on  the  resource.!; 
opNetworkNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  opNetworkName  attribute  changes  value.!; 

A.4.2.21  OMNIPoint  Version  Package 

opVersionPkg    PACKAGE    --  refinement  of  Rec.  M.3100  versionPackage 

BEHAV I OUR     opVers  i  onPkgDef  i  ni  t  i  on, 
opVers  i  onPkgBehavi  our ; 

ATTRIBUTES 

"Rec.  M.3100  :  1992": vers ion 

PERMITTED  VALUES  SYNTAX- 1 .GraphicString16  GET-REPLACE; 

REGISTERED  AS    Cx-package  21>; 
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opVers i onPkgDef  i ni  t i on  BE HAVl OUR 
DEFINED  AS 

IThis  package  reflects  the  release  version  of  the  underlying  resource  as  an  attribute,  as  defined  by 
"Rec.  M.3100  :  1992".!; 


opVersionPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

•If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
'  package,  this  notification  is  emitted  when  the  Version  attribute  changes  value.!; 

i 

A.4.2.22  Outgoing  Protocol  Error  Package 

outgoingProtocolErrorPkg  PACKAGE 

BEHAVIOUR    outgoingProtocolErrorPkgDef inition, 
outgoingProtocolErrorPkgBehaviour; 

I  ATTRIBUTES 

I  "Rec.  X.721  j  ISO/IEC  10165-2  :  1992":outgoingProtocolErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 

ij    REGISTERED  AS    {x- package  22>; 


outgoingProtocolErrorPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  reflects  the  capability  of  the  underlying  resource  to  count  the  number  of  outgoing 
protocol  errors  detected.    Note  that  not  all  resources  have  this  capability.!; 


i|    outgoingProtocolErrorPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

•If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  outgoingProtocolErrorCounter  attribute  wraps. I; 

A.4.2.23  PDUs  Retransmitted  Counter  Package 

pdusRetransmi  ttedCounterPkg  PACKAGE 

BEHAVIOUR    pdusRet  ransmi  t tedCounterPkgDef  i  ni  t  i  on, 
pdusRetransmittedCounterPkgBehaviour; 

ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":pdusRetransmittedErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 

REGISTERED  AS    Cx-package  23>; 


pdusRetransmi  t tedCounterPkgDef  i  ni  t  i  on  BEHAVIOUR 

DEFINED  AS  y 

!This  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  count  the 
number  of  PDUs  retransmitted.!; 
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pdusRetransmi  ttedCounterPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

fif  the  attn'buteValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  PDUsRetransmittedCounter  attribute  wraps.!; 


A.4.2.24  PDUs  Retransmitted  Threshold  Package 

pdusRetransmi  ttedThresholdPkg  PACKAGE 

BEHAVIOUR    pdusRetransmittedThresholdPkgDef inition, 
pdusRet  ransmi  1 1 edThresho IdPkgBehav  i  our ; 

ATTRIBUTES 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":pdusRetransmittedErrorThreshold  GET-REPLACE; 
NOTIFICATIONS 

"Rec,  X.721  j  ISO/IEC  10165-2  :  1992":coninunicationsAlarm; 
REGISTERED  AS    Cx-package  24}; 


pdusRetransmi ttedThresholdPkgDef ini t ion  BEHAVIOUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  threshold  the 
number  of  PDUs  retransmitted.!; 


pdusRetransmi ttedThresholdPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

IWhen  a  new  Transport  Connection  instance  is  created  containing  this  package,  any  "0P1  Library  Vol. 
2  :  1992":transportConnectionRetransmissionIVM0  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance. 

If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this  package, 
this  notification  is  emitted  when  the  pdusRetransmi ttedThreshold  attribute  changes  in  value.!; 


A.4.2.25  Peripheral  List  Package 

peripheralListPkg  PACKAGE 

BEHAVIOUR     peripheral ListPkgDef inition, 
peripheralListPkgBehaviour; 

ATTRIBUTES 

peripheralList    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 
REGISTERED  AS  Cx-package  25>; 


per  i  phera I L  i  stPkgDef  i  n  i  t  i  on  BE  HAV I OUR 
DEFINED  AS 

•The  Peripheral  List  attribute  identifies  auxiliary  devices  that  are  used  by  the  resource  (e.g., 
disk  drives,  tape  drives,  printers).!; 


per i  phera I L  i  s tPkgBehav i  our  BEHAV I OUR 
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DEFINED  AS 

I  If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Peripheral  List  attribute  changes  value. I ; 


I   A.4.2.26  Peripheral  Name  Package 

I    peripheralNamePkg  PACKAGE 

BEHAVIOUR     peripheralNamePkgDef inition, 
peripheralNamePkgBehaviour; 

ATTRIBUTES 

peripheral Name   PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 
REGISTERED  AS         {x-package  26}; 


per  i phera I NamePkgDef  i ni  t  i  on  BEHAV I OUR 
DEFINED  AS 

!The  Peripheral  Name  attribute  identifies  an  auxiliary  device  that  is  used  by  the  resource  (e.g., 
disk  drive,  tape  drive,  printer).!; 


peripheralNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Peripheral  Name  attribute  changes  value.!; 


A.4.2.27  Processing  Entity  List  Pacl(age 

processingEntityListPkg  PACKAGE 

BEHAVIOUR     process  i  ngEnt  i  tyL  i  stPkgDef  i  ni  t  i  on, 
process i ngEnt i tyL i stPkgBehavi our ; 

ATTRIBUTES 

process i ngEnt i tyL i St    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  AOO-REMOVE; 
1     REGISTERED  AS         {x-package  27}; 


processingEnt i  tyL i stPkgDef  i ni  t i on  BEHAVI OUR 
DEFINED  AS 

!The  Processing  Entity  List  attribute  identifies  the  processing  entities  which  may  be  used  by  the 
containing  object  instance  but  which  are  not  contained  in  it  (i.e.,  processing  entities  which  are 
shared  among  systems).!; 


process i ngEnt  i  tyL  i s tPkgBehav i  our  BE HAVI OUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Processing  Entity  List  attribute  changes  value. I; 


A.4.2.28  Processing  Entity  Name  Pacl(age 
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process ingEntityNamePkg  PACKAGE 

BEHAVIOUR     process ingEntityNamePkgDefi nit  ion, 
process i ngEnt i tyNamePkgBehavi our ; 

ATTRIBUTES 

process i ngEnt ityName    PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 
REGISTERED  AS  {x-package  28}; 


processi ngEnt i  tyNamePkgDef  i ni  t  i on  BEHAVI OUR 
DEFINED  AS 

!The  Processing  Entity  Name  attribute  identifies  the  processing  entity  which  may  be  used  by  the 
containing  object  instance  but  which  is  not  contained  in  it  (i.e.,  processing  entities  which  are 
shared  among  systems).!; 


processi ngEnt i tyNamePkgBehavi our  BEHAVIOUR 
DEFINED  AS 

■If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Processing  Entity  Name  attribute  changes  value.!; 


A.4.2.29  Product  Label  Package 


productLabelPkg  PACKAGE 

BEHAVIOUR     product LabelPkgDefi nit  ion, 
productLabelPkgBehaviour; 

ATTRIBUTES 

productLabel    PERMITTED  VALUES  SYNTAX-1 .GraphicString32  GET-REPLACE; 
REGISTERED  AS  {x-package  29}; 


productLabelPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  allows  the  product  number  or  identifying  string  (e.g.,  model  number)  of  the  underlying 
resource  to  be  reflected  as  an  attribute.!; 


productLabelPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Product  Label  attribute  changes  value.!; 


A.4.2.30  Retransmission  Time  Package 


retransmissionTimePkg  PACKAGE 

BEHAV I OUR    ret  ransmi  ss  i  onT  i  mePkgDef  i  ni  t  i  on, 
retransmissionTimePkgBehaviour; 
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ATTRIBUTES 

retransmissionTime  PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 
REGISTERED  AS    <x-package  30>; 
ret  ransni  ss  i  onT  i  inePkgOef  i  n  i  t  i  on  BE  HAV I  OUR 
DEFINED  AS 

(This  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  present  its 
current  retransmission  timer  value  as  an  attribute.!; 


ret  r ansmi  ss  i  onT  i  meP  kgBehaviour  BEHAVIOUR 
DEFINED  AS 

lUhen  a  new  Transport  Connection  instance  is  created  containing  this  package,  the  initial  value  of 
this  attribute  may  be  provided  by  the  retransmissionTimerlnitialValue  attribute  (if  present  in  the 
new  managed  object  instance).!; 


A.4.2.31  Retransmission  Timer  Initial  Value  Package 


retransmi  ss  i  onT  i  mer I ni  t  i  a I Va I uePkg  PACKAGE 

BEHAVIOUR    retransmi  ss i  onT  i mer I ni  t  i a I Va I uePkgDef  i ni  t  i on, 
ret  ransmi  ss i  onT  i mer I n i  t  i  a  I Va I uePkgBehavi  our ; 

ATTRIBUTES 

retransmissionTimerlnitialValue  PERMITTED  VALUES  SYNTAX-1.Integer32  GET; 
REGISTERED  AS    (x-package  31>; 

retransfflissionTimerlnitialValuePkgOef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  present  its 
initial  retransmission  timer  value  as  an  attribute.!; 


retransmi  ss  i  onT  i  mer I n  i  t  i  a I Va I uePkgBehav  i  our    BE  HAV I OUR 
DEFINED  AS 

lUhen  a  new  Transport  Connection  instance  is  created  containing  this  package,  any  "0P1  Library  Vol. 
2  :  1992":transportConnectionRetransmissionIVMO  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance.!; 


A.4.2.32  Serial  Number  Package 


serialNumberPkg  PACKAGE 

BEHAVIOUR     serialNumberPkgDef inition. 

ser  i  alNumlserPkgBehavi  our; 

ATTRIBUTES 

serialNumber     PERMITTED  VALUES  SYNTAX-1 .GraphicString32  GET-REPLACE; 
REGISTERED  AS  <x-package  32>; 
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serialNumiserPkgDefinition  BEHAVIOUR 
DEFINED  AS 

IThis  package  allows  the  serial  number  of  the  underlying  resource  to  be  reflected  as  an  attribute. I; 

serialNumberPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 

package,  this  notification  is  emitted  when  the  Serial  Number  attribute  changes  value.!;  j 

A.4.2.33  Service  List  Package 

serviceListPkg      PACKAGE  | 

BEHAV I OUR  servi ceL  i  stPkgDef  i ni  t i on, 

serviceListPkgBehaviour;  j 

ATTRIBUTES     servi ceLi St     PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  AOD-REMOVE; 

REGISTERED  AS  <x- package  33>; 

serviceListPkgDef inition  BEHAVIOUR  1 
DEFINED  AS 

{Service  List  attribute  identifies  any  services  that    are  supported  by  the  resource.!; 
serviceListPkgBehaviour  BEHAVIOUR 

DEFINED  AS  j 
!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  serviceList  attribute  changes  value.!;  | 

A.4.2.34  Service  Name  Package 

servi ceNamePkg  PACKAGE 

BEHAVIOUR  servi ceNamePkgDef inition, 
servi  ceNamePkgBehavi  our; 

i 

ATTRIBUTES     serviceName     PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  {x-package  34>;  j 

i 

servi ceNamePkgDef inition  BEHAVIOUR 
DEFINED  AS 

{Service  Name  attribute  identifies  any  service  that  is  supported  by  the  resource.!; 
servi ceNamePkgBehavi our  BEHAVIOUR 
DEFINED  AS 

■If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 

package,  this  notification  is  emitted  when  the  serviceName  attribute  changes  value.!;  ^ 

A.4.2.35  Software  List  Package  i 

softwareListPkg  PACKAGE 

BEHAVIOUR  softwareLi StPkgDef inition. 
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sof twareL  i  stPkgBehavi  our; 
ATTRIBUTES    softwareList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  AOD-REHOVE; 
REGISTERED  AS  (x-package  35>; 
sof  twareL  i  stPkgDef  i  n  i  t  i  on   BE  HAV I OUR 
DEFINED  AS 

IThe  Software  List  attribute  identifies  those  software  components  that  run  on  or  are  considered  part 
of  the  resource.!; 

softwareLi StPkgBehavi our  BEHAVIOUR 

DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  softwareList  attribute  changes  value.!; 

A.4.2.36  Software  Name  Package 

softwareNamePkg  PACKAGE 

BEHAVIOUR  softwareNamePkgDef inition, 
sof  twareNamePkgBehav  i  our ; 

ATTRIBUTES    softwareName  PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  Cx-package  36>; 

SoftwareNamePkgDef inition  BEHAVIOUR 

DEFINED  AS 

IThe  Software  Name  attribute  identifies  the  software  component  that  runs  on  or  are  considered  part 
of  the  resource. ! ; 

softwareNamePkgBehaviour  BEHAVIOUR 

DEFINED  AS 

llf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  softwareName  attribute  changes  value.!; 

A.4.2.37  System  Time  Package 

systemT  i  mePkg  PACKAGE 

BEHAVIOUR     systemTimePkgOef inition, 
systemTimePkgBehaviour; 

ATTRIBUTES 

systemTime   PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 
REGISTERED  AS         Cx-package  37>; 

systemTimePkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  records  the  current  time  clocked  by  the  resource.!; 
systemTimePkgBehaviour  BEHAVIOUR 
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DEFINED  AS 

!The  attribute  contained  in  this  package  is  never  the  subject  of  an  attribute  value  change 
notification.    Even  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class 
using  this  package,  this  notification  is  NOT  emitted  when  the  systemTime  attribute  changes  value. I; 


A.4.2.38  Type  Text  Package 


typeTextPkg  PACKAGE 

BEHAVIOUR  typeTextPkgOefinition, 
type! extPkgBehavi our; 

ATTRIBUTES 

typeText     PERMITTED  VALUES  SYNTAX- 1 .GraphicString32  GET-REPLACE; 
REGISTERED  AS  <x-package  38>; 


typeTextPkgOefinition  BEHAVIOUR 
DEFINED  AS 

IThis  package  serves  to  supplement  and  refine  individual  managed  object  class  attributes!; 


typeTextPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Type  Text  attribute  changes  value. I; 


A.4.2.39  Up  Time  Package 

upTimePkg  PACKAGE 

BEHAVIOUR     upTimePkgDef inition, 
upT  i  mePkgBehav  i  our ; 

ATTRIBUTES 

upTime    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 
REGISTERED  AS  {x-package  39}; 


upTimePkgDef inition  BEHAVIOUR 
DEFINED  AS 

•This  package  records  the  elapsed  time  during  which  the  underlying  resource  has  been  enabled.!; 


upTi mePkgBehav i our  BEHAVIOUR 
DEFINED  AS 

!The  attribute  contained  in  this  package  is  never  the  subject  of  an  attribute  value  change 
notification.    Even  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class 
using  this  package,  this  notification  is  NOT  emitted  when  the  upTime  attribute  changes  value.!; 
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A.4.2.40  Usage  State  Package 


usaoeStatePkg  PACKAGE 

BEHAVIOUR  usageStatePkgOefinition, 
usageStatePkgBehaviour; 

ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992'*:usageState  GET; 

ATTRIBUTE  GROUPS 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":8tate 

••Rec.  X.721  I  ISO/IEC  10165-2  :  1992":usageState; 

REGISTERED  AS  {x-package  40>; 


usageStatePkgOefinition  BEHAVIOUR 
DEFINED  AS 

IThis  package  specifies  the  Usage  State  of  the  underlying  resource,  to  be  included  in  resources 
which  are  able  to  detect  whether  or  not  they  are  currently  in  use.!; 


usageStatePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

I  If  the  stateChange  notification  is  defined  for  the  managed  object  class  using  this  package,  this 
notification  is  emitted  when  the  usageState  attribute  changes  value.!; 


A.4.2.41  Vendor  Ust  Package 

vendorListPkg  PACKAGE 

BEHAVIOUR  vendorListPkgOefinition. 

vendorL  i  stPkgBehavi  our; 

ATTRIBUTES    vendorList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  <x-package  41>; 


vendorListPkgOefinition  BEHAVIOUR 
DEFINED  AS 

IThe  Vendor  List  attribute  identifies  the  organization(s)  from  which  the  resource  was  obtained 
(e.g.,  purchased,    leased,  etc.)!; 

vendorL i StPkgBehavi our  BEHAVIOUR 

DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  vendorList  attribute  changes  value.!; 


A.4.3  Name  Bindings 


A.4.3.1  Computer  System  Name  Bindings 


59 


PART  18:  Network  Management 


December  1992  (Stable) 


computerSystem- system  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992": system; 
WITH  ATTRIBUTE  con^xjterSystemld; 

CREATE    WITH-REFERENCE-OBJECT,  UITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  <x-nameBinding  1>; 


computerSystem- opNetwork  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS        opNetwork  AND  SUBCLASSES; 
WITH  ATTRIBUTE  computerSystemId; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE    ONLY-IF-NO-CONTAINED-OBJECTS;  i 

il 

REGISTERED  AS  (x-nameBinding  2>; 

computerSystem-computerSystem      NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    computerSystem  AND  SUBCLASSES;  j 
NAMED  BY  ] 
SUPERIOR  OBJECT  CLASS        computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE  ComputerSystemId; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  {x-nameBinding  3>; 

A.4.3.2  CO  Transport  Protocol  Layer  Entity  Name  Bindings 

coTransportProtocolLayerEntity-computerSystem    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    coTransportProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE  coTransportProtocolLayerEntityld; 
REGISTERED  AS    Cx-nameBinding  4>; 

coTransportProtocolLayerEntity-system    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    coTransportProtocolLayerEntity  AND  SUBCLASSES;  ^ 
NAMED  BY  ' 
SUPERIOR  OBJECT  CLASS  ' 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":  system  AND  SUBCLASSES; 
WITH  ATTRIBUTE  coTransportProtocolLayerEntityld; 

REGISTERED  AS    {x-nameBinding  5); 

coTransportProtocolLayerEnti ty-opEquipment    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    coTransportProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  opEquipment  AND  SUBCLASSES;  'i 
WITH  ATTRIBUTE  coTransportProtocolLayerEnt i tyld;  '| 
REGISTERED  AS    {x-nameBinding  6>; 


A.4.3.3  CL  Network  Protocol  Layer  Entity  Name  Bindings 

clNetworkProtocolLayerEntity-computerSystem    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  clNetworkProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 
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SUPERIOR  OBJECT  CLASS  computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE  clNetworkProtocolLayerEntityld; 
REGISTERED  AS    <x-nameBinding  7>; 

clNetworkProtocolLayerEntity-system   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  cINetworkProtocolLayerEnti ty  AND  SUBCLASSES; 
;  NAMED  BY 

SUPERIOR  OBJECT  CLASS 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":  system  AND  SUBCLASSES; 
WITH  ATTRIBUTE  ClNetworkProtocolLayerEntityld; 
REGISTERED  AS    {x-nameSinding  8>; 

{  clNetworkProtocolLayerEntity-opEquipment    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  clNetworkProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

I  SUPERIOR  OBJECT  CLASS  opEquipment  AND  SUBCLASSES; 

UITH  ATTRIBUTE  ClNetworkProtocolLayerEntityld; 
REGISTERED  AS    {x-nameBinding  9>; 

j  A.4.3.4  OMNIPoint  Equipment  Name  Bindings 

opEquipment-computerSystem  NAME  BINDING 

I      SUBORDINATE  OBJECT  CLASS    opEquipment  AND  SUBCLASSES; 
'      NAMED  BY 

SUPERIOR  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992":equipmentld; 

CREATE    UITH-REFERENCE-OBJECT,  UITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  <x-nameBinding  10}; 

'I 

li  opEquipment-system  NAME  BINDING 

I      SUBORDINATE  OBJECT  CLASS    opEquipment  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS    "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":system; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992": equipment  Id; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINED-OBJECTS; 

t  REGISTERED  AS  {x-nameBinding  11>; 

i't 

'  opEquipment -equipment           NAME  BINDING 

I  SUBORDINATE  OBJECT  CLASS  opEquipment  AND  SUBCLASSES; 
NAMED  BY 

I  SUPERIOR  OBJECT  CLASS    "Rec.  M.3100  :  1992": equipment  AND  SUBCLASSES; 

I  WITH  ATTRIBUTE    "Rec.  M.3100  :  1992": equipment  Id; 

I  CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

'  DELETE  ONLY-IF-NO-CONTAINED-OBJECTS; 

■    REGISTERED  AS  Cx-nameBinding  12>; 

opEquipment-opNetwork  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opEquipment  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS        opNetwork  AND  SUBCLASSES; 
I      WITH  ATTRIBUTE    "Rec.  M.3100  :  1992": equipment  Id; 
|l         CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC-INSTANCE-NAMIHG; 
DELETE  ONLY-IF-NO-COHTAINED-OBJECTS; 

REGISTERED  AS  {x-nameBinding  13}; 

II 

A.4.3.5  OMNIPoint  Network  Name  Bindings 
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--  The  following  name  bindings  are  defined,  in  addition  to  those 

--  inherited  from  Rec.  H.3100  Network  (which  do  not  include  CREATE/DELETE): 

network-opNetwork-1  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opNetwork  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS    "Rec.  H.3100  :  1992":network  AND  SUBCLASSES; 
WITH  ATTRIBUTE    "Rec,  M.3100  :  1992":networkId; 

CREATE    UITH-REFERENCE-OBJECT,  UITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINEO-OBJECTS; 

REGISTERED  AS  {x-nameBinding  14>; 


network-opNetwork-2  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opNetwork  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "Rec.  M.3100  :  1992":network  AND  SUBCLASSES; 
WITH  ATTRIBUTE  networkTitle; 

CREATE    UITH-REFERENCE-OBJECT,  UITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  15>; 


opNetwork- root  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opNetwork  AND  SUBCLASSES; 

NAMED  BY  SUPERIOR  OBJECT  CLASS  "Rec.  X.660  |  ISO/IEC  9834-1  :  1992":root; 
WITH  ATTRIBUTE  networkTitle; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  (x-nameBinding  16>; 


A.4.3.6  Processing  Entity  Name  Bindings 

--  processingEntity-opEquipment  NAME  BINDING 
--  processingEntity-computerSystem  NAME  BINDING 

--  both  inherited  from  opEquipment,  no  additional  bindings  required. 


A.4.3.7  Transport  Connection  Name  Bindings 

transportConnection-coTransportProtocolLayerEntity   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  transportConnection  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  coTransportProtocolLayerEntity  AND  SUBCLASSES; 
WITH  ATTRIBUTE  transportConnectionId; 
BEHAVIOUR  transportConnectionNBBehaviour; 
DELETE  DELETES-CONTAINED-OBJECTS; 
REGISTERED  AS    Cx-nameBinding  17>; 


t ransport Connect  i onNBBeha v i  our  BEHAV I OUR 
DEFINED  AS 

!The  expected  real  effect  of  the  DELETE  operation  when  applied  to  an  instance  of  the  transport 
connection  managed  object  class  is  that  the  underlying  transport  connection  resource  is  aborted.!; 
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A.4.4  Attributes 

A.4.4.1  Active  Connections 

act  iveConnect ions  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR    act iveConnect ionsBehaviour; 

REGISTERED  AS        <x-attribute  1>; 

i| 

I  activeConnectionsBehaviour  BEHAVIOUR 

•I 
I 

!  DEFINED  AS 

•The  act iveConnect ions  attribute  specifies  the  number  of  currently  active  transport  connections 
(i.e.,  the  number  of  transport  connections  which  are  in  the  open  state  [as  defined  for  the 
underlying  protocol  machine],  updated  upon  each  connection  establishment  and  release).!; 


A.4.4.2  Addressing  Size 

1  address ingSize  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .Address ingSizeBase; 
MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR  addressingSizeBehaviour; 

REGISTERED  AS  {x-attribute  2>; 

addressingSizeBehaviour  BEHAVIOUR 

i 

I  DEFINED  AS 

!The  Addressing  Size  attribute  indicates  the  number  of  bits  which  represent  an  address  to  the 
Processing  Entity's  central  processing  unit  (CPU).!; 


A.4.4.3  Checksun  POUs  Discarded  Counter 
checksumPDUsD  i  scardedCounter     ATTR I  BUTE 
DERIVED  FROM 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR    ChecksumPDUsD iscardedCounterBehavi our; 

I  REGISTERED  AS        <x-attribute  3>; 

\  checksumPDUsD iscardedCounterBehavi our  BEHAVIOUR 

1  DEFINED  AS 

!The  attribute  specifies  the  number  of  well-formed  PDUs  rejected  by  the  peer  entity  due  to  a 
checksum  error. ! ; 

I 

I  A.4.4.4  Computer  System  Id 

'  computerSystemld  ATTRIBUTE 

,  WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .GraphicStringBase; 

I  MATCHES  FOR    EQUALITY,  SUBSTRINGS; 

I  BEHAVIOUR  computerSystemldBehaviour; 
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REGISTERED  AS        Cx-attribute  4>; 
computerSystemldBehaviour  BEHAVIOUR 
DEFINED  AS 

■The  computerSystemld  attribute  is  the  distinguishing  attribute  for  the  computerSysteni  managed 

object  class.!; 

A.4.4.5  CL  l^etwork  Protocol  Layer  Entity  Id 

clNetworkProtocolLayerEntityld  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .GraphicStringBase; 

MATCHES  FOR    EQUALITY,  SUBSTRINGS; 

BEHAVIOUR  clNetworkProtocolLayerEntityldBehaviour; 

REGISTERED  AS        Cx-attribute  5>; 

clNetworkProtocolLayerEnti tyldBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  ClNetworkProtocolLayerEntityld  attribute  is  the  distinguishing  attribute  for  the 
clNetworkProtocolLayerEntity  managed  object  class.!; 

AAAM  CO  Transport  FrotocoS  Layer  Entity  Id 

coT  ranspor tProtoco I LayerEnt  i  ty I d   ATTR I  BUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .GraphicStringBase; 

MATCHES  FOR    EQUALITY,  SUBSTRINGS; 

BEHAVIOUR    coTransportProtocol LayerEnt i tyldBehaviour; 

REGISTERED  AS        {x-attribute  6>; 

coTransportProtocolLayerEnt i  tyldBehaviour  BEHAVIOUR 

DEFINED  AS 

•The  coTransportProtocolLayerEntityld  attribute  is  the  distinguishing  attribute  for  the 
coTransportProtocol LayerEnt ity  managed  object  class.!; 

A.4.4.7  Contact  List 

contactList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  contactListBehaviour; 

REGISTERED  AS  (x-attribute  7>; 

contactListBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Contact  List  attribute  provides  managed  object  instance  information  for  one  or  more  contacts. 
The  following  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid  as 
contacts:  "0P1  Library  Vol.  4": Contact. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.S  Contact  Name 
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contactName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNatneBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  contactNameBehaviour; 

REGISTERED  AS  {x-attribute  8>; 

contactNameBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Contact  Name  attribute  provides  information  for  one  person  or  organization  who  can  be 
contactacted  about  the  resource. I; 

A.4.4.9  CPU  Type 

cpuType  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .Graph icStri ngBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  cpuTypeBehaviour; 

REGISTERED  AS  {x-attribute  9}; 

cpuTypeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Central  Processor  Unit  (CPU)  Type  attribute  indicates  the  type  of  central  processor  unit  found 
in  a  Processing  Entity.!; 

A.4.4.10  CPU  Utilization 

cpuUtilization  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 . IntegerBase; 
HATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR    cpuUti I izationBehaviour; 

REGISTERED  AS  {x-attribute  10>; 

cpuUti I izationBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  cpuUtilization  attribute  specifies,  as  a  percentage,  the  overall  utilization  of  all  central 
processor  units  found  in  a  processing  entity.    The  percentage  is  expressed  as  an  integer  with 
permissible  values  in  the  range  of  0  to  100.!; 

A.4.4.11  Customer  List 

customerList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX-1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  customerListBehaviour; 

REGISTERED  AS  Cx-attribute  11>; 

customerListBehaviour  BEHAVIOUR 

DEFINED  AS 
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I  The  Customer  List  attribute  provides  managed  object  instance  information  about  one  or  more 
customers.    The  following  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid  as 
customers:  "0P1  Library  Vol.  4":Customer. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute. I; 

A.4.4.12  Customer  Name 


customerName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
HATCHES  FOR  EQUALITY.  SUBSTRINGS; 
BEHAVIOUR  customerNameBehaviour; 

REGISTERED  AS  (x-attribute  12}; 

customerNameBehaviour  BEHAVIOUR 

DEFINED  AS 

■The  Customer  Name  attribute  provides  information  about  one  customer.!; 

A.4.4.13  Endianess 

endianess  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .Endianess; 
MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR  endianessBehaviour; 

REGISTERED  AS  {x-attribute  13>; 

endianessBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Endianess  attribute  indicates  the  bit  order  (big  endian,  little  endian)  used  by  the  Processing 
Entity's  central  processing  unit  (CPU).!; 


A.4.4.14  Function  List 

functionList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  functionListBehaviour; 

REGISTERED  AS  Cx-attribute  14>; 

functionListBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Function  List  attribute  provides  managed  object  instance  information  about  one  or  more 
functions.    The  following  managed  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes) 
are  valid  as  functions:    "0P1  Library  Vol.  4":Function. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.15  Function  Name 
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functionName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY.  SUBSTRINGS; 
BEHAVIOUR  functionNameBehaviour; 

REGISTERED  AS  Cx-attribute  15>; 

functionNameBehaviour  BEHAVIOUR 

DEFINED  AS 

(The  Function  Name  attribute  provides  information  about  one  function.l; 

A.4.4.16  Inactivity  Time 

inactivityTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .HundredthsOf Sec; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  inactivityTimeBehaviour; 

REGISTERED  AS         {x-attribute  16}; 

inactivityTimeBehaviour  BEHAVIOUR 

DEFINED  AS 

!This  attribute  specifies  the  amount  of  time  (in  1/IOOths  of  a  second)  that  the  transport  connection 
has  been  inactive.!; 

A.4.4.17  Inactivity  Timeout 

inactivityTimeout  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .HundredthsOf Sec; 

MATCHES  FOR      EQUALITY,  ORDERING; 

BE  HAV I OUR    { nac  t  i  V  i  t yT  i  meou t  Behav  i  our; 

REGISTERED  AS  (x-attribute  17>; 

inactivityTimeoutBehaviour  BEHAVIOUR 

DEFINED  AS 

!This  attribute  specifies  the  maximum  amount  of  time  (in  1/100ths  of  a  second)  that  the  transport 
connection  can  remain  enabled  when  there  is  no  activity  (i.e.,  data  flow  )  on  it.    A  value  of  0  for 
this  attribute  indicates  that  an  inactivity  timeout  is  not  supported  on  the  transport  connection.!; 

A.4.4.18  Local  Network  Address 

localNetworkAddress  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .Address; 
MATCHES  FOR       EQUALITY,  SUBSTRINGS; 
BEHAV I OUR    I oca I Networ kAddr essBehav  i  our ; 

REGISTERED  AS         tx-attribute  18>; 

loca I NetworkAddressBehav  i  our     BE  HAV I OUR 

DEFINED  AS 

!The  localNetworkAddress  attribute  identifies  the  local  network  address  supported  by  a  network 
protocol  layer  entity  (e.g.,  local  IP  address  for  TCP  or  the  local  NSAP  address  for  OSI).!; 
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A.4.4.19  Local  Network  Addresses 

localNetworkAddresses  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX       SYNTAX- 1 .NetworkAddresses; 
MATCHES  FOR      SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  localNetworkAddressesBehaviour; 

REGISTERED  AS  {x-attnbute  19); 

localNetworkAddressesBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  localNetworkAddresses  attribute  identifies  the  local  network  addresses  supported  by  a  network 
protocol  layer  entity  (e.g.,  local  IP  address  for  TCP  or  the  local  NSAP  address  for  OSI). 

Set  comparison  and/or  set  intersection  matching  rules  may  not  be  supported  by  some  managed  object 
instances  which  include  this  attribute.!; 

A.4.4.20  Local  Transport  Addresses 

localTransportAddresses  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .TransportAddresses; 
MATCHES  FOR      SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR    loca I T  ransportAddressesBehavi  our ; 

REGISTERED  AS    {x-attribute  20); 

localTransportAddressesBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  localTransportAddresses  attribute  specifies  the  set  of  local  transport  addresses  (e.g,  local 
TSAP  identifiers)  that  a  connection  oriented  transport  protocol  layer  entity  provides  to  its  users. 
A  transport  address  consists  of  a  transport  connection  endpoint  and  a  network  address. 

Set  comparison  and/or  set  intersection  matching  rules  may  not  be  supported  by  some  managed  object 
instances  which  include  this  attribute.!; 

A.4.4.21  Local  Transport  Connection  Endpoint 

I oca I T  r anspcr  t Connec  t  i  onEndpo i  nt  AT T R I  BUTE 

WITH  ATTRIBUTE  SYNTAX      SYNTAX- 1 .Address; 

MATCHES  FOR      EQUALITY,  SUBSTRINGS; 

BE HAV I OUR     I oca  I T  ranspor  t  Connec  t  i  onEndpo i  nt Beha v i  our ; 

REGISTERED  AS  {x-attribute  21); 

localTransportConnectionEndpointBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  identifies  the  local  transport  connection  endpoint  (e.g.,  the  source  port  for  TCP  or 
the  local  t-selector  for  OSI  Transport  protocol).!; 

A.4.4.22  Location  Pointer 

locationPointer  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .Objectlnstance; 
MATCHES  FOR  EQUALITY; 
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BEHAVIOUR  locationPointerBehaviour; 


REGISTERED  AS  <x-attribute  22>; 


locationPointerBehaviour 


BEHAVIOUR 


DEFINED  AS 


I  The  Location  Pointer  attribute  provides  managed  object  instance  information  for  a  location  (e.g. 
Hilo  Hawaii  USA).  The  following  managed  object  classes  (or  any  of  their  subclasses  or  allonorphi 
classes)  are  valid  as  locations:    "0P1  Library  Vol.  4":Location.i; 


A.4.4.23  Manufacturer  List 

i  manufacturerList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNamesBase; 
I  MATCHES  FOR    SUBSTRINGS,  SET -COMPARISON,  SET- INTERSECTION; 

BEHAVIOUR  manufacturerListBehaviour; 

,  REGISTERED  AS         <x-attribute  23}; 

manufacturerListBehaviour  BEHAVIOUR 

!{  DEFINED  AS 

I  I  The  manufacturerList  attribute  indicates  information  about  the  manufacturer(s)  that  manufactured 

}  the  underlying  resource.    This  attribute  contains  object  instance  name(s)  for  "0P1  Library  Vol. 

4":manufacturer  (or  any  subclass  or  allomorphic  class). 


Set  comparison  and/or  set  intersection  matching  rules  may  not  be  supported  by  some  managed  object 
instances  which  include  this  attribute.!; 


j  A.4.4.24  Manufacturer  Name 

,  manufacturerName  ATTRIBUTE 

I 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR    EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  manufacturerNameBehaviour; 

REGISTERED  AS         Cx-attribute  24}; 

I  manufacturerNameBehaviour  BEHAVIOUR 

DEFINED  AS 


!The  manufacturerName  attribute  indicates  information  about  the  manufacturer(s)  that  manufactured 
the  underlying  resource.    This  attribute  contains  descriptive  text. I; 


WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  maxCormectionsBehaviour; 

REGISTERED  AS        {x-attribute  25}; 

maxCormectionsBehaviour  BEHAVIOUR 

DEFINED  AS 


A.4.4.25  Max  Connections 


I  maxConnections 


ATTRIBUTE 
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!The  maxConnections  attribute  specifies  the  maximum  number  of  simultaneously  active/open  transport 
connections  that  can  be  supported  by  the  transport  protocol  layer  entity. I; 

A.4.4.26  Max  PDU  Size 

maxPDUSize  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  maxPOUSizeBehaviour; 

REGISTERED  AS        (x-attribute  26>; 

maxPDUSizeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  maxPDUSize  attribute  specifies  the  maximum  length  of  a  PDU  that  can  be  supported  by  the  local 
layer  entity. < ; 

A.4.4.27  Max  Retransmissions 

maxRetransmissions  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 . IntegerBase; 
HATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  maxRetransmissionsBehaviour; 

REGISTERED  AS        Cx-attribute  27>; 

maxRet  ransmi  ss  i  onsBehav  i  our     BEHAV I OUR 

DEFINED  AS 

IThis  attribute  specifies  the  maximum  number  of  times  a  TPDU  is  to  be  retransmitted  before  the 
transport  connection  is  aborted.!; 

A.4.4.28  Memory  Size 

memorySize  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .HemorySizeBase; 
MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR  memorySizeBehaviour; 

REGISTERED  AS  {x-attribute  28); 

memorySizeBehaviour  BEHAVIOUR 

DEFINED  AS 

•The  Memory  Size  attribute  indicates,  in  kilobytes,  the  amount  of  memory  available  to  a  Processing 
Entity  (irrespective  of  its  current  usage).!; 

A.4.4.29  Memory  Utilization 

memoryUti lization  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 . IntegerBase; 

MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR    memoryUti I izationBehavi our; 

REGISTERED  AS  <x-attribute  29>; 
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mefluryUtilizationBehaviour  BEHAVIOUR 
DEFINED  AS 

!The  memoryUti lization  attribute  specifies,  as  a  percentage,  the  overall  utilization  of  amount  of 
memory  available  to  a  processing  entity.    The  percentage  is  expressed  as  an  integer  with  permissible 
values  in  the  range  of  0  to  100.1; 

A.4.4.30  Network  Entity  Type 

networkEntityType  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .NetworkEnti tyType; 

HATCHES  FOR  EQUALITY; 

BEHAVIOUR  networkEntityTypeBehaviour; 

REGISTERED  AS         {x-attribute  30>; 

networ kEnt  i  tyTypeBehavi  our     BE  HAV I OUR 

DEFINED  AS 

(The  networkEntityType  attribute  indicates  the  type  of  the  network  protocol  layer  entity.!; 

A.4.4.31  Netvtrork  Title 

networkTitle  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  j  ISO/IEC  10165-2  :  1992":systemTitle; 
BEHAVIOUR  networkTitleBehaviour; 

REGISTERED  AS  €x-attribute  31>; 

networkTitleBehaviour  BEHAVICXJR 

DEFINED  AS 

!The  Network  Title  is  one  of  the  distinguishing  attribute  the  network  managed  object  class  for  use 
as  described  in  clause  6.3  of  [MIM]!; 

A.4.4.32  NPDU  Time  To  Live 

nPOUTimeToLive  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 . IntegerBase; 
HATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVI OUR    nPDUT  i  meToL  i  veBehavi  our; 

REGISTERED  AS  <x-attribute  32>; 

nPOUTimeToLiveBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  maximum  amount  of  time  (in  units  of  10  ms)  that  an  NPDU  can  exist  in 
the  network.    This  attribute  is  used  to  limit  the  lifetime  of  NPDUs  during  unstable  network 
situations. ! ; 

A.4.4.33  OIVINIPoint  Equipment  List 

opEquiproentList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX-1 .AnyNamesBase; 
HATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  opEquipmentListBehaviour; 
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REGISTERED  AS  {x-attribute  33>; 
opEquipmentListBehaviour  BEHAVIOUR 
DEFINED  AS 

!The  OMNIPoint  Equipment  List  attribute  provides  managed  object  instance  information  about  one  or 
more  pieces  of  opEquipment.    The  following  classes  (or  any  of  their  subclasses  or  allomorphic 
classes)  are  valid  as  equipment:  OMNIPoint  Equipment. 

The  SET -COMPARISON  and/or  SET- INTERSECT  ION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.34  OMNIPoint  Network  List 

opNetworkList  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON.  SET- INTERSECT  ION; 
BEHAVIOUR  opNetworkListBehaviour; 

REGISTERED  AS  {x-attribute  34>; 

opNetworkListBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  OMNIPoint  Network  List  attribute  shall  provide  managed  object  instance  information  about  a  set 
of  networks.    The  following  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are 
valid  as  networks:  OMNIPoint  Network. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.35  OMNIPoint  Network  Name 

opNetworkNanne  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  opNetworkNameBehaviour; 

REGISTERED  AS  Cx-attribute  35>; 

opNetworkNameBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  OMNIPoint  Network  Name  attribute  shall  provide  information  about  a  network.!; 

A.4.4.36  Operating  System  Information 

oslnfo  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .OsInfoBase; 

MATCHES  FOR  EQUALITY,  SET -COMPARISON,  SET- INTERSECTION; 

BEHAVIOUR  osInfoBehaviour; 

REGISTERED  AS  <x-attribute  36>; 

osInfoBehaviour  BEHAVIOUR 

DEFINED  AS 

■The  Operating  System  Information  attribute  specifies  the  names  and  releases  of  the  supported 
operating  systems. 
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The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.37  PDUs  Forwarded  Counter 

pdusForwardedCounter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR  pdusForwardedCounterBehaviour; 

REGISTERED  AS        <:x-attribute  37>; 

pdusForwardedCounterBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  number  of  valid  incoming  PDUs  which  were  forwarded  (transmitted  as 
outgoing  PDUs)  to  another  destination.    This  attribute  does  not  count  incoming  PDUs  which  were 
delivered  to  a  local  service  user.!; 

A.4.4.38  PDUs  Reassembled  Ok  Counter 

pdusReasmbldOKCounter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR  pdusReasmbldOKCounterBehaviour; 

REGISTERED  AS        <x-attribute  38>; 

pdusReasmbldOKCounterBehaviour  BEHAVIOUR 

DEFINED  AS 

!This  attribute  specifies  the  number  of  PDUs  that  were  reassembled  successfully  by  a  protocol  layer 
entity. ! ; 

A.4.4.39  PDUs  Reassembled  Fall  Counter 

pdusReasmbldFai ICounter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR    pdusReasmbldFai ICounterBehaviour; 

REGISTERED  AS        {x-attribute  39>; 

pdusReasmbldFai ICounterBehaviour  BEHAVIOUR 

DEFINED  AS 

!This  attribute  specifies  the  number  of  valid  PDUs  received  by  a  protocol  layer  entity  but  discarded 
due  to  reassembly  failure.    This  attribute  counts  only  incoming  PDUs  which  were  recognized  as  valid 
segments  of  an  SDU,  but  which  were  discarded  during  reassembly  (for  example,  due  to  reassembly  time 
expiration). ! ; 

A.4.4.40  PDUs  Discarded  Counter 

pdusDiscardedCounter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  [  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR  pdusDiscardedCounterBehaviour; 

REGISTERED  AS        {x-attribute  AO; 

pdusD  i  scardedCount erBehav  i  our     BE  HAV I OUR 
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DEFINED  AS 

IThis  attribute  specifies  the  number  of  invalid  PDUs  received  and  discarded  by  a  protocol  layer 
entity. I; 

A.4.4.41  Periplraral  Ust 

peripheralList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNamesBase; 

MATCHES  FOR  EQUALITY,  SET -COMPARISON,  SET- INTERSECTION; 

BEHAVIOUR  peripheralListBehaviour; 

REGISTERED  AS  {x-attribute  41>; 

peripheralListBehaviour  BEHAVIOUR 

DEFINED  AS 

I  The  Peripheral  List  attribute  provides  managed  object  instance  information  for  peripheral  devices 
accessible  by  a  resource. 

The  Peripheral  List  attribute  identifies  the  auxiliary  devices  that  are  used  by  a  resource.  This 
includes  things  such  as  disk  drives,  tape  drives,  printers,  etc. 

The  following  object  classes  (or  their  subclasses  or  allomorphic  classes)  are  valid  processing 
entities:  OMNIPoint  Equipment. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.42  Peripheral  Name 

peripheral Name  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  peripheralNameBehaviour; 

REGISTERED  AS  <x-attribute  42>; 

peripheralNameBehaviour  BEHAVIOUR 

DEFINED  AS 

I  The  Peripheral  Name  attribute  provides  information  for  peripheral  devices  accessible  by  a  resource. 

The  Peripheral  Name  attribute  identifies  an  auxiliary  devices  that  is  used  by  a  resource.  This 
includes  things  such  as  disk  drives,  tape  drives,  printers,  etc.!; 

A.4.4.43  Processing  Entity  Ust 

processingEntityList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNamesBase; 

MATCHES  FOR  EQUALITY,  SET -COMPARISON,  SET- INTERSECTION; 

BEHAVIOUR  processingEntityListBehaviour; 

REGISTERED  AS  <x-attribute  43>; 

processi  ngEnt  i  tyL  i  stBehavi  our  BEHAVIOUR 

DEFINED  AS 
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!The  Processing  Entity  List  attribute  specifies  the  processing  entities  which  may  be  used  by  the 
containing  object  instance  but  which  are  not  contained  in  (i.e.,  processing  entities  which  are 
shared  among  systems).    The  following  object  classes  (or  their  subclasses  or  allomorphic  classes) 
are  valid  processing  entities:  processingEntity. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute. >; 

A.4.4.44  Processing  Entity  Name 

process ingEntityName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 

MATCHES  FOR  EQUALITY,  SUBSTRINGS; 

BE  HAV I OUR    process  i  ngEnt  i  tyNameBehav  i  our ; 

REGISTERED  AS  (x-attribute  44>; 

processi  ngEnt  i  tyNameBehav  i  our  BEHAV I OUR 

DEFINED  AS 

!The  Processing  Entity  Name  attribute  specifies  the  processing  entity  which  may  be  used  by  the 
containing  object  instance  but  which  is  not  contained  in  (i.e.,  processing  entities  which  are  shared 
among  systems).!; 

A.4.4.45  Product  Label 

productLabel  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .GraphicStringBase; 
MATCHES  FOR      EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  productLabelBehaviour; 

REGISTERED  AS  {x-attribute  45>; 

productLabelBehaviour  BEHAVIOUR 

DEFINED  AS 

•The  productLabel  attribute  specifies  the  product  number  or  identifying  string  (e.g.,  model  number) 
of  the  underlying  resource.!; 

A.4.4.46  Remote  Netv\/ork  Address 

remoteNetworkAddress  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .Address; 
MATCHES  FOR       EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  remoteNetworkAddressBehaviour; 

REGISTERED  AS  Cx-attribute  A6>; 

'  remoteNetworkAddressBehavi  our     BEHAVI OUR 

DEFINED  AS 

!The  remoteNetworkAddress  attribute  identifies  the  remote  network  address  of  a  transport  connection 
(e.g.,  remote  IP  address  for  TCP  or  the  remote  NSAP  address  for  OSI).!; 

A.4.4.47  Remote  Transport  Connection  Endpoint 

remoteT  ranspor tConnect  i  onEndpoi  nt         ATTR I  BUTE 
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WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .Address; 
MATCHES  FOR      EQUALITY,  SUBSTRINGS; 

BEHAVIOUR  remoteTransportConnectionEndpointBehaviour; 
REGISTERED  AS         Cx-attribute  47>; 
remoteT  ranspor t Connec  t  i  onEndpo  i  n t  Beha v  i  our     BE  HAV I OUR 
DEFINED  AS 

IThis  attribute  identifies  the  remote  transport  connection  endpoint  (e.g.,  the  destfnation  port  for 
TCP  or  the  remote  t-selector  for  OSI  Transport  protocol).!; 

A.4.4.48  Retransmission  Time 

retransmissionTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .HundredthsOf Sec; 
HATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  retransmissionTimeBehaviour; 

REGISTERED  AS        (x-attribute  48>; 

retransmissionTimeBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  current  value  (in  1/100ths  of  a  second)  of  the  retransmission  timer 
used  by  a  transport  connection.); 

A.4.4.49  Retransmission  Timer  Initial  Value 

ret  ransmi  ss  i  onT  i  mer I ni  t  i  a I Va I ue   ATTR I  BUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .HundredthsOf Sec; 

MATCHES  FOR      EQUALITY,  ORDERING; 

BEHAV I OUR    ret  ransmi  ss  i  onT  i  mer I n  i  t  i  a  I Va I ueBehavi  our; 

REGISTERED  AS        {x-attribute  49>; 

ret  ransmi  ss  i  onT  i  mer I n  i  t  i  a I Va I ueBehav  i  our     BEHAV I OUR 

DEFINED  AS 

■This  attribute  specifies  the  initial  value  (in  1/100ths  of  a  second)  of  the  retransmission  timer 
used  by  a  transport  connection.!; 

A.4.4.50  Serial  Number 

serialNumber  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .GraphicStringBase; 
HATCHES  FOR      EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  serialNumberBehaviour; 

REGISTERED  AS  Cx-attribute  S0>; 

serialNumberBehaviour  BEHAVIOUR 

DEFINED  AS 

I  The  serialNumber  attribute  provides  the  serial  number  of  the  underlying  resource. I; 

A.4.4.51  Service  List 
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serviceList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON.  SET- INTERSECT ION; 
BEHAVIOUR  serviceListBehaviour; 

REGISTERED  AS  {x-attribute  51}; 

serviceListBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  Service  List  attribute  provides  managed  object  instance  information  about  one  or  more  services. 
The  following  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid  as 
services:  "0P1  Library  Vol.  4":Service. 

The  SET-COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.52  Service  Name 

serviceName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  serviceNameBehaviour; 

REGISTERED  AS  <x-attribute  52>; 

serviceNameBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  Service  Name  attribute  provides  information  about  one  service. I; 

A.4.4.53  Software  List 

softwareList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  softwareListBehaviour; 

REGISTERED  AS  Cx-attribute  53>; 

softwareListBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  Software  List  attribute  identifies  those  software  components  that  run  on  or  are  considered  part 
of  the  equipment.    (There  is  no  corresponding  managed  object  class  at  this  time.) 

The  SET-COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.S4  Software  Name 

softwareName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVICXJR  softwareNameBehaviour; 

REGISTERED  AS  {x-attribute  54>; 
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softwareNameBehaviour  BEHAVIOUR 
DEFINED  AS 

!The  Software  Name  attribute  identifies  the  software  component  that  tlhis  on  or  are  considered  part 
of  the  equipment.); 

A.4.4.55  System  Time 

system! i me  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .Genera I Time; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  systemTimeBehaviour; 

REGISTERED  AS        Cx-attribute  55>; 

systemTimeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  systemTime  attribute  specifies  the  current  time  clocked  at  the  resource.!; 

A.4.4.56  Transport  Connection  Id 

transportConnectionId  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .GraphicStringBase; 
MATCHES  FOR    EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  transportConnectionldBehaviour; 

REGISTERED  AS        Cx-attribute  56>; 

transportConnectionldBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  transportConnectionId  attribute  is  the  distinguishing  attribute  for  the  transportConnection 
managed  object  class.!; 

A.4.4.57  Transport  Connection  Reference 

t ransportConnect  i  onRef erence  ATTR I  BUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 . IntegerBase; 

MATCHES  FOR  EQUALITY; 

BEHAVIOUR    t ransportConnect ionReferenceBehavi our; 
REGISTERED  AS         Cx-attr ibute  57>; 
t ransportConnect ionReferenceBehavi our  BEHAVIOUR 
DEFINED  AS 

!This  attribute  identifies  the  local  transport  connection  reference  that  is  established  by  the  two 
transport  connection  endpoints  (e.g.,  the  local  soclcet  number  for  TCP  or  the  local  connection  j 
reference  for  OSI).!;  •' 

I: 

A.4.4.58  Transport  Entity  Type 

'I 

transportEntityType  ATTRIBUTE  j 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .TransportEntityType; 
MATCHES  FOR  EQUALITY; 


78 


PART  18:  Network  Management 


December  1992  (Stable) 


BEHAVIOUR  transportEntityTypeBehaviour; 
REGISTERED  AS         <x-attribute  58>; 
transportEnt  i  tylypeBehavi  our  BEHAVIOUR 
DEFINED  AS 

!The  transportEntityType  attribute  indicates  the  type  of  the  transport  protocol  layer  entity. I; 
A.4.4.59  Type  Text 

typeText  ATTRIBUTE 

UITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .GraphicStringBase; 
MATCHES  FOR      EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  typeTextBehaviour; 

REGISTERED  AS         {x-attribute  59>; 

typeTextBehaviour  BEHAVIOUR 

DEFINED  AS 

■The  typeText  attribute  serves  to  supplement  and  refine  individual  managed  object  class  attributes. 
If  none  of  the  named  items  defined  for  the  "type"  attribute  are  appropriate,  or  the  "type"  attribute 
requires  refinement,  the  typeText  attribute  contains  supplemental  information.!; 

A.4.4.60  Up  Time 

upTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  upTimeBehaviour; 

REGISTERED  AS        Cx-attribute  60}; 

upTimeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  upTime  attribute  specifies  the  time  interval  (in  seconds)  that  has  elapsed  since  the  entity's 
operational  state  changed  to  "enabled",  or  since  the  time  that  the  entity  was  created  in  the 
"enabled"  state.!; 


A.4.4.61  Vendor  List 

vendorList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX-1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  vendorListBehaviour; 

REGISTERED  AS  <x-attribute  61>; 

vendorListBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Vendor  List  attribute  provides  managed  object  instance  information  about  a  set  of  vendor 
organizations.  The  following  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid 
as  vendors:    "0P1  Library  Vol.  4": Vendor. 
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The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute. !; 


A.4.5  Actions 


A.4.5.1  Activate 

Copied  from  ISO/IEC  DIS  10737,  should  be  replaced  by  reference  to  standard 
--  definition  when/if  this  ACTION  is  registered  in  a  final  IS  version. 

activate  ACTION 

BEHAVIOUR  activateBehaviour; 
MODE  CONFIRMED; 

WITH  REPLY  SYNTAX  SYNTAX-1 .ActivateActionReply; 
REGISTERED  AS  (  x-action  1  >; 


activateBehaviour  BEHAVIOUR 
DEFINED  AS 

I  This  action  initializes  the  operation  of  the  resource.    As  a  result  of  the  action,  the  sequence  of 
operations  necessary  to  cause  the  resource  to  enter  its  operational  mode  shall  be  initiated.  These 
may  include,  for  example,  checks  against  attribute  constraint  violation  and  checks  on  the  validity 
of  relationship  attributes  (cross- layer  and  other).    If  these  operations  are  successfully  initiated, 
the  administrative  state  (if  present)  shall  be  changed  to  "unlocked"  and  the  value  "successResponse" 
shall  be  returned  in  the  responseCode  parameter  of  the  action  reply.    If  these  operations  cannot  be 
successfully  initiated,  the  value  "fai lureResponse"  shall  be  returned,  together  with  a  failure 
reason  parameter  describing  the  reason  for  the  failure.    On  successful  completion  of  these 
operations,  the  operational  state  shall  have  the  value  "enabled".    Depending  upon  the  current  state 
of  the  resource  when  the  action  is  attempted,  some  or  all  of  the  above  operations  may  be 
unnecessary.!; 

A.4.5.2  Deactivate 

--  Copied  from  ISO/IEC  OIS  10737,  should  be  replaced  by  reference  to  standard 
--  definition  when/if  this  ACTION  is  registered  in  a  final  IS  version. 

deactivate  ACTION 

BEHAVIOUR  deactivateBehaviour; 
MODE  CONFIRMED; 

WITH  REPLY  SYNTAX  SYNTAX-1 .ActivateActionReply; 
REGISTERED  AS  {  x-action  2  >; 


deactivateBehaviour  BEHAVIOUR 
DEFINED  AS 

■This  action  terminates  the  operation  of  the  resource.    As  a  result  of  the  action,  the  sequence  of 
operations  necessary  to  cause  the  resource  to  cease  operation  shall  be  initiated.    If  these 
operations  are  successfully  initiated,  the  administrative  state  (if  present)  shall  be  changed  to 
"locked"  and  the  value  "successResponse"  shall  be  returned  in  the  responseCode  parameter  of  the 
action  reply.    If  these  operations  cannot  be  successfully  initiated,  the  value  "fai lureResponse" 
shall  be  returned,  together  with  a  failure  reason  parameter  describing  the  reason  for  the  failure. 
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On  successful  completion  of  these  operations,  the  operational  state  shall  have  the  value  "disabled". 
Depending  upon  the  current  state  of  the  resource  when  the  action  is  attenpted,  some  or  all  of  the 
above  operations  may  be  unnecessary.!; 


A.4.6  Parameters 


A.4.6.1  Transport  Disconnect  Cause 

transportDisconnectCause  PARAMETER 

CONTEXT      EVENT- INFO; 

WITH  SYNTAX  SYNTAX- 1 .Cause; 

BEHAVIOUR  causeBehaviour; 

REGISTERED  AS  i  x-parameter  1  >; 


causeBehaviour  BEHAVIOUR 
DEFINED  AS 

IThis  parameter  specifies  the  reason  why  a  transport  connection  was  deleted.  It  may  be  included  in 
the  Additional  Information  parameter  of  the  objectDeletion  notification.!; 


A.4.7  Syntax  Definitions 

SYNTAX- 1  {  x-module  1  } 
DEFINITIONS  IMPLICIT  TAGS  ::=  BEGIN 

IMPORTS  DistinguishedName  FROM  InformationFramework  {joint- iso-ccitt  ds(5)  modules(l) 

informationFrameworkd )>  Objectlnstance  FROM  CMIP-1  {joint- iso-ccitt  ms(9)  cmip(l)  modules(0}  protocol(3)>; 


EXPORTS  everything 


The  following  OIDs  are  allocated  from  the  OIU  NMSIG  registration  arc, 
for  use  in  registering  harmonized  OIW/NMF  definitions. 


nmsig  OBJECT  IDENTIFIER 

opiLibraryVoll  OBJECT  IDENTIFIER 

x-module  OBJECT  IDENTIFIER 

x-objectClass  OBJECT  IDENTIFIER 

x-package  OBJECT  IDENTIFIER 

x-nameBinding  OBJECT  IDENTIFIER 

x-attribute  OBJECT  IDENTIFIER 

x-attributeGroup  OBJECT  IDENTIFIER 

x-parameter  OBJECT  IDENTIFIER 

x-action  OBJECT  IDENTIFIER 

x-notif ication  OBJECT  IDENTIFIER 

x-responseCode  OBJECT  IDENTIFIER 


=  { 

=  { 

=  i 

=  { 

=  < 

=  < 

=  < 

=  i 

=  i 

=  { 

=  { 

=  { 


iso  identif ied-organization<3)  oiw(K)  nmsig(2) 
nmsig  2  } 

> 
> 
> 
> 

> 
> 
> 
> 
> 


op1L 
op1L 
op1L 
op1L 
op1L 
op1L 
op1L 
oplL 
oplL 
oplL 


braryVoll 
braryVoll 
braryVoll 
braryVoll 
braryVoll 
braryVoll 
braryVoll 
braryVoH 
braryVoll  8 
braryVoU  9 


By  convention,  the  postfix  "base"  is  used  when  defining  base  types  which  appear 
•-     as  syntax  labels  in  ATTRIBUTE  templates  and  the  postfix  "range"  is  used  when  defining 
constrained  types  which  appear  as  syntax  labels  in  PERMITTED  VALUES  clauses. 
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Act  i  vateAct  i  onReply 


SEQUENCE  { 

responseCode 
responseArgs 
> 


OBJECT  IDENTIFIER, 

SET  OF  Parameter  OPTIONAL 


OBJECT  IDENTIFIER  values  used  with  ActivateActionReply  -- 
fai lureResponse  OBJECT  IDENTIFIER  ::=  {  x- responseCode  1  > 
successResponse   OBJECT  IDENTIFIER  ::=    i  x- responseCode  2  > 


Address 


:=    OCTET  STRING 


Address  i  ngS  i  zeBase 


::=  CHOICE  C 

unknown  NULL, 

address ingSize  IntegerBase 


measured  in  bits 


Address  i  ngS  i  zeRange 


::=  CHOICE  { 

unknown  NULL, 

address ingSize       IntegerBase  (1..64) 


-  measured  in  bits 


AnyNamesBase 
AnyNameBase 


SET  OF  Objectlnstance 
Graph  i  cSt  r  i  ngBase 


AnyNannesRange 
AnyNameRange 


::=  SET  S1ZE(0..64)  OF  Objectlnstance 
::=    Graph icString64 


Cause 


::=    SEQUENCE  { 


who  INTEGER  < 

unknown  (0), 
user  (1), 
provider  (2) 
>. 

why  INTEGER  { 

unknown  (0), 
excessiveldle  (1), 
excess iveRetransmiss ions  (2) 
» 


Endianess 


ENUMERATED  { 

big  (1), 
little  (2) 


Equi  pment I dRange 


CHOICE  i 

based  on  "Rec.  M.3100  :  1992"  ASN.1  Module  NameType 
numericName  Integer32, 
pString  Graph icString64 

> 


GeneralTime 


GeneralizedTime 


Graph  i  cSt  r  i  ngBase 
GraphicString16 


GraphicString 

GraphicStringBase(SIZE(0..16)) 
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Graph icString32 
Graph icString64 


GraphicStringBase(SIZE(0..32)) 
GraphicStringBase(SIZE(0..64)) 


HundredthsOfSec 


::=  IntegerBase 


IntegerBase 
Integer32 


:-  INTEGER 

:=    I ntegerBase(0.. 4294967295) 


MeniorySizeBase 


CHOICE  < 
unknown  NULL, 

size  IntegerBase         measured  in  kilobytes 

> 


MemorySizeRange   ::=  CHOICE  { 

unknown  NULL, 

size 

> 


Integer32        --  measured  in  kilobytes 


NetworkEnt  i  tyType 


::=  INTEGER  i  Other  (0), 

oSI-clnp  (1), 

internet- IP  (2) 
>  (0..255) 


NetworkAddresses 


:=    SET  OF  Address 


OsInfoBase 


OsInfoRange 


SET  OF  SEQUENCE 
i 

osName  GraphicStringSase, 
osRelease  Graph icStringBase 
> 

SET  OF  SEQUENCE 
{ 

osName  GraphicString64, 
osRelease  GraphicString64 
> 


Parameter 


SEQUENCE  { 

paramid      OBJECT  IDENTIFIER, 
paramlnfo   ANY  DEFINED  BY  paramid 
> 


PercentageRange 


:=    IntegerBase  (0..100) 


TransportAddresses 
TransportAddress 


:=    SET  OF  TransportAddress 


SEQUENCE  < 
transportConnectionEndpoint  Address, 
networkAddress  Address 
> 
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TransportEnti tyType 


11'  INTEGER  {  other 

oSI-TP 

tCP 

SNA 

)  (0..255) 


(0)  , 

(1)  . 

(2)  . 
(3) 


END 


A.4.8  Inheritance  &  Naming  Trees 

This  section  provides  graphic  depictions  for  the  inheritance  and  naming  trees  that  are  defined  in  the 
previous  sections. 

A.4.8. 1 1nheritance  Tree 


♦--  computerSystem 

♦--  opNetwork 

-  coT ransportProtocol LayerEnt i  ty 

♦--  c I Networ ((Protocol LayerEnt  ity 

+--  transportConnection 

A.4.8.2  Naming  Tree 

root  •+--  opNetwork  opNetwork 


♦--  DMI  system         coT ransportProtocol LayerEnt ity  transportConn 


♦--  c I NetworkProtocol LayerEnt ity 


♦--  opEquipment-*--  opEquipment 

♦--  process ingEnt ity 

coTransportProtocolLayerEntity  transportConn 
clNetworkProtocolLayerEntity 


+--  computerSystem  computerSystem 
♦--  process ingEnt ity 
*--  opEquipment 


top  opEquipment 


process ingEnt ity 


■»■■ 


computerSystem 


opEquipment 
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coTransportProtocolLayerEntity  --  transportConn 
+--  clNetworkProtocolLayerEntity 


A.5  OIW  NMSiG  IVMO  Definitions 

The  definitions  specified  in  tfiis  clause  can  be  referenced  by  using  tiie  label  "0P1  Library  Vol.  2"  (e.g., 
"0P1  Library  Vol.  2":transportConnectionlVMO). 

A.5.1  Managed  Object  Classes  and  Mandatory  Packages 

A.5. 1.1  Transport  Connection  IVMO 


transportConnectlonlVMO     MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  X.721  j  ISO/IEC  10165-2  :  1992":top; 
CHARACTERIZED  BY  transportConnectionlVMO-Package; 

REGISTERED  AS  Cy-objectClass  1>; 


transportConnectionlVMO-Package  PACKAGE 

BE  HAV lOUR    transport  Connec  t  i  on I VMO - beha v  i  our ; 
ATTRIBUTES 

transportConnectionlVMOId  GET, 

"0P1  Library  Vol.  1": inactivityTimeout    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET-REPLACE, 
"0P1  Library  Vol.  V'lmaxPDUSize    PERMITTED  VALUES  SYNTAX- 1 . Inte9er32  GET-REPLACE; 
NOTIFICATIONS 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":objectCreation, 
"Rec.  X.721  ISO/IEC  10165-2  :  1992":objectDeletion, 
"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":attributeValueChange;; 


transportConnectionl VMO- behaviour  BEHAVIOUR 
DEFINED  AS 

■This  managed  object  class  is  an  IVMO  (Initial  Value  Managed  Object  class).    It  represents 
the  collection  of  characteristic  attributes  which  supply  default  and  initially  advertised 
attribute  values  to  be  used  by  instances  of  the  Transport  Connection  managed  object  class 
when  they  are  created.    There  can  be  only  one  instance  of  the  Transport  Connection  IVMO 
managed  object  class  for  each  instance  of  the  CO  Transport  Protocol  Layer  Entity  managed 
object  class.    Each  Transport  Connection  IVMO  instance  may  provide  initial  attribute  values 
for  newly-created  Transport  Connection  instances  with  the  same  superior. 

The  Attribute  List  parameter  of  the  ObjectCreation  notification  shall  contain  all  the 
attributes  of  the  created  transport  connection  IVMO  instance. 

The  Attribute  List  parameter  of  the  ObjectDeletion  notification  shall  contain  all  the 
attributes  of  the  deleted  transport  connection  IVMO  instance. 

Attributes  that  are  subject  to  the  AttributeValueChange  notification  are  :  "0P1  Library 
Vol.  1": inactivityTimeout,  "0P1  Library  Vol.  1":maxPDUSize.    All  attributeValueChange 
notifications  shall  include  the  Attribute  Identifier  List  parameter.!; 


A.5. 1.2  Transport  Connection  Retransmission  IVMO 
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trensportConnectionRetransmissionlVMO     MANAGED  OBJECT  CLASS 
DERIVED  FROM  transportConnectionlVMO; 

CHARACTERIZED  BY  transportConnectionRetransmissionlVMO-Package; 
REGISTERED  AS    (y-objectClass  3>; 


t ransportConnect  i  onRet ransmi  ss  i  onl VMO- Package  PACKAGE 
BE  HAV I OUR    t  ranspor  t Connec  t  i  on I VMO*  behav  i  our ; 
ATTRIBUTES 

"0P1  Library  Vol.  1":n)axRet ransmi ssions  PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET-REPLACE, 
"0P1  Library  Vol.  1":retransmissionTimerInitialValue 

PERMITTED  VALUES  SYNTAX- 1.1nte9er32  GET-REPLACE;; 


t  ransportConnect  i  onRet  ransmi  ss  i  on I VMO- behav i  our    BEHAVI OUR 
DEFINED  AS 

•This  managed  object  class  is  an  IVMO  (Initial  Value  Managed  Object  class).    It  represents 
the  collection  of  characteristic  attributes  which  supply  default  and  initially  advertised 
attribute  values  to  be  used  by  instances  of  the  Transport  Connection  managed  object  class 
-         that  support  retransmission,  when  they  are  created.    There  can  be  only  one  instance  of  the 
Transport  Connection  Retransmission  IVMO  managed  object  class  for  each  instance  of  the  CO 
Transport  Protocol  Layer  Entity  managed  object  class.    Each  Transport  Connection 
Retransmission  IVMO  instance  may  provide  initial  attribute  values  for  newly-created 
Transport  Connection  instances  with  the  same  superior. 

Attributes,  additional  to  those  inherited  from  the  transport  connection  IVMO  managed  object 
class,  that  are  subject  to  the  AttributeValueChange  notification  are  :  "0P1  Library  Vol. 
1":maxRetransmi ssions,  "0P1  Library  Vol.  1":retransmissionTimerInitialValue. ! ; 


A.5.2  Name  Bindings 


A.5.2.1  Transport  Connection  IVMO  Name  Bindings 

transportCormectionlVMO-coTransportProtocolLayerEntity   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  t ransportConnect i onl VMO  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "OPI  Library  Vol.  1":coTransportProtocolLayerEntity  AND  SUBCLASSES; 
WITH  ATTRIBUTE  transportConnectionlVMOId; 
REGISTERED  AS    Cy-nameBinding  1}; 


A.5.2.2  Transport  Connection  Retransmission  IVMO  Name  Bindings 

transportConnectionRetransmissionlVMO-coTransportProtocolLayerEntity  NAME  BINDING 
SUBORDINATE  OBJECT  CLASS  t ransportConnect i onRet ransmi ssi onl VMO 
AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "0P1  Library  Vol.  1":coTransportProtocolLayerEntity  AND  SUBCLASSES; 
WITH  ATTRIBUTE  transportConnectionlVMOId; 
REGISTERED  AS    Cy-nameBinding  2>; 


A.5.3  Attributes 
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A.5.3.1  Transport  Connection  IVIMO  Id 


transportConnectionlVMOId  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .GraphicStringBase; 

MATCHES  FOR      EQUALITY,  SUBSTRINGS; 

BEHAVIOUR  transportConnectionlVHOIdBehaviour; 


REGISTERED  AS 


ty-attribute  1>; 


transportConnectionlVMOIdBehaviour  BEHAVIOUR 

DEFINED  AS  IThis  attribute  is  the  distinguishing  attribute  for  the  managed  object  class 

transportConnectionlVMO. ! ; 

A.5.4  Syntax  Definitions 

SYNTAX-2  <  y-module  1  > 
DEFINITIONS  IMPLICIT  TAGS  ::=  BEGIN 

EXPORTS  everything 

The  following  OIDs  are  allocated  from  the  OIU  NMSIG  registration  arc, 
for  use  in  registering  OIW  NMSIG  MIL  definitions. 


rvnsig  OBJECT  IDENTIFIER 

op1LibraryVol2  OBJECT  IDENTIFIER 

y-module  OBJECT  IDENTIFIER 

y-objectClass  OBJECT  IDENTIFIER 

y-package  OBJECT  IDENTIFIER 

y-nameBinding  OBJECT  IDENTIFIER 

y-attribute  OBJECT  IDENTIFIER 

y-attributeGroup  OBJECT  IDENTIFIER 

y-parameter  OBJECT  IDENTIFIER 

y-action  OBJECT  IDENTIFIER 

y-notif ication  OBJECT  IDENTIFIER 


iso  identif ied-organization(3)  oiw(14)  nmsig(2) 
nmsig  1  } 

> 
> 
> 
> 

> 
> 
> 

oplLibraryVolZ  8  } 


op1LibraryVol2  0 
op1LibraryVol2  1 
oplLibraryVol2  2 
oplLibraryVol2 
oplLibraryVol2 
op1LibraryVol2 
oplLibraryVol2 
op1LibraryVol2 


END 


A.5.5  Inheritance  &  Naming  Trees 

This  section  provides  graphic  depictions  for  the  inheritance  and  naming  trees  that  are  defined  in  the 
previous  sections. 

A.5.5. 1  Inheritance  Tree 


top    transportConnectionlVMO 


transportConnectionRetransmissionlVMO 


A.5.5.2  Naming  Tree 


coTransportProtocolLayerEntity  -+--  transportConnection 
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*"  transportConnectionlVMO 
I 

♦--  transportConnectionRetransmissionlVHO 

A.6  OIW  NMSIG  Shared  Management  Knowledge  (SMK)  Definitions 
(Refer  to  the  Working  Implementation  Agreements  Document.) 
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Annex  B  (informative) 


NMSIG  Object  Identifiers 

(Refer  to  the  Working  implementation  Agreements  Document  for  additional  information.) 
B.I  Introduction 

This  Annex  (B)  specifies  object  identifier  component  values  which  are  globally  unambiguous.  These  object 
identifiers  are  to  be  used  when  referencing  NMSIG-specified  information  objects.  As  defined  in  Part  6  of 
these  agreements,  the  OIW  has  assigned  the  following  object  identifier  for  use  by  the  NMSIG: 

{  iso(1)  identified-organi2ation(3)  oiw(14)  nmsig(2)  } 

The  following  object  identifiers  are  assigned  under  the  {  iso  identified-organization  oiw  nmsig  }  node, 
labelled  "nmsig". 


Table  B.1  -  Object  Sdentifiers  assigned  under  "nmsig"  node 


Identifier 

Value 

Reference 

op1LibraryVol2 

1 

A. 5 

opiLibraryVoll 

2 

A. A 

,  By  inclusion  of  the  managed  object  (MO)  definitions  and  the  object  identifiers  in  Annex  A  and  Annex  B, 
'   respectively,  of  the  Stable  Implementors'  Agreements  (SI As),  these  managed  object  (MO)  definitions  have 
I  become  formally  registered.  Implementors  of  part  1 8  of  the  SIAs  do  not  have  to  support  any  of  these  MOs. 
I  However,  even  though  Annex  A  and  Annex  B  are  informative  annexes,  any  implementation  that  claims  to 
,   conform  to  these  definitions  must  treat  these  definitions  as  normative  and  comply  with  the  relevant  portions 
of  Annex  A.4  and  A.5,  and  Annex  B. 


B.2  Harmonized  MIL  Object  Identifiers 


Harmonized  MIL  Object  Identifiers  are  assigned  under  the  "nmsig"  node  as  follows: 


nmsig 

OpiLibraryVoll 
x-module 

objectClass 

package 

nameBinding 

attribute 

attributeGroup 

parameter 
x-action 
x-notif ication 
X- responseCode 


OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 


IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 
IDENTI 


FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 
FIER 


=  {  iso  identif ied-organization(3)  oiw(14)  nmsig(2)  > 

=  {  nmsig  2  } 

=  {  opiLibraryVoll  0  > 

=  {  opiLibraryVoll  1  } 

=  i  opiLibraryVoll  2  > 

=  {  opiLibraryVoll  3  > 

=  i  opiLibraryVoll  4  > 

=  {  opiLibraryVoll  5  } 

=  {  opiLibraryVoll  6  > 

=  {  opiLibraryVoll  7  } 

=  {  opiLibraryVoll  8  } 

=  {  opiLibraryVoll  9  } 


l'  B.2.1  Object  Class  Object  identifiers 
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The  following  object  identifiers  are  assigned  under  the  {  x-objectClass  }  node: 

Table  B.2  -  Object  identifiers  assigned  under  "x-objectClass"  node 


Reference 

Identifier 

Value 

A. 4. 1.1 

computerSystem 

1 

A. 4. 1.2 

coTransportProtocolLayerEnt i  ty 

2 

A. 4. 1.3 

clNetworkProtocolLayerEnti  ty 

3 

A. 4. 1.4 

opEquipment 

4 

A. 4, 1.5 

opNetMork 

5 

A. 4. 1,6 

process  i  ngEnt  i  ty 

6 

A. 4. 1.7 

t  ranspor  t  Connec  t  i  on 

7 

B.2.2  Package  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-package  }  node: 


Table  B.3  -  Object  identifiers  assigned  under  "x-package"  node 


Reference 

Identifier 

Value 

A. 4. 2.1 

address ingPkg 

1 

A. 4. 2. 2 

checksumPDUsD  i  scardedPkg 

2 

A. 4. 2. 3 

contactListPkg 

3 

A. 4. 2. 4 

contactNamePkg 

4 

A. 4. 2. 5 

cpuUti I izationPkg 

5 

A. 4. 2. 6 

customerL  istPkg 

6 

A. 4. 2. 7 

customerNamePkg 

7 

A. 4. 2. 8 

functionListPkg 

8 

A. 4. 2. 9 

functionNamePkg 

9 

A. 4. 2. 10 

incomingProtocolErrorPkg 

10 

A. 4. 2. 11 

locat ionPointerPkg 

11 

A. 4. 2. 12 

manuf acturerL  i  stPkg 

12 

A. 4. 2. 13 

nnanufacturerNamePkg 

13 

A. 4. 2. 14 

maxPDUSizelVPkg 

14 

A. 4. 2. 15 

maxRetransmissionsPkg 

15 
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Reference 

Identifier 

Value 

A.4.2.16 

memorySizePkg 

16 

A.4.2.17 

memoryUt  i I i  zat  i  onPkg 

17 

A. 4. 2. 18 

octetsRetranstni  ttedPkg 

18 

A. 4. 2. 19 

opNetworkL  i  stPkg 

19 

A. 4. 2. 20 

opNetworkNamePkg 

20 

A.4.2.21 

opVersionPkg 

21 

A. 4. 2. 22 

outgoingProtocolErrorPkg 

22 

A.4.2.23 

pdusRetransmi  ttedCounterPkg 

23 

A. 4. 2. 24 

pdusRet ransmi  1 1 edTh resho IdPkg 

24 

A.4.2.25 

peripheralListPkg 

25 

A. 4. 2. 26 

per  i  phera I NamePkg 

26 

A.4.2.27 

process  i  ngEnt  i  tyL  i  s tPkg 

27 

A. 4. 2. 28 

process  i  ngEnt  i  tyNamePkg 

28 

A. 4. 2. 29 

productLabelPkg 

29 

A. 4. 2. 30 

ret  ransm  i  ss  i  onT  i  tnePkg 

30 

A. 4. 2. 31 

ret  ransmi  ss  i  onT  i  mer I ni  t  i  a I Va I uePkg 

31 

A. 4. 2. 32 

serialNumberPkg 

32 

A. 4. 2. 33 

serviceListPkg 

33 

A. 4. 2. 34 

serviceNamePkg 

34 

A. 4. 2. 35 

sof twareListPkg 

35 

A. 4. 2. 36 

sof twareNamePkg 

36 

A. 4. 2. 37 

system! imeP kg 

37 

A. 4. 2. 38 

typeTextPkg 

38 

A. 4. 2. 39 

upTimePkg 

39 

A. 4. 2. 40 

usageStatePkg 

40 

A. 4. 2. 41 

vendorListPkg 

41 

B.2.3  Name  Bindings  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-nameBinding  }  node: 
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Table  B.4  -  Object  identifiers  assigned  under  "x-nameBindlng"  node 


Reference 

Identifier 

Value 

A. 4. 3. 2 

computerSystem- system 

1 

A. 4. 3. 2 

computerSystem-opNetwork 

2 

A. 4. 3. 2 

computerSystem- computerSystem 

3 

A. 4. 3. 3 

coTransportProtocolLayerEnt i ty-computerSystem 

4 

A. 4. 3. 3 

coT ransportProtoco I LayerEntity- system 

5 

A. 4. 3. 3 

coTransportProtocolLayerEnti ty-opEquipment 

6 

A. 4. 3. 4 

clNetworkProtocolLayerEnt i  ty- computerSystem 

7 

A. 4. 3. 4 

clNetworkProtocolLayerEnt i  ty-system 

8 

A. 4. 3. 4 

clNetworkProtocolLayerEnti ty-opEquipment 

9 

A. 4. 3. 5 

opEquipment -computerSystem 

10 

A. 4. 3. 5 

opEqui  pment -  system 

11 

A. 4. 3. 5 

opEquipment -equipment 

12 

A. 4. 3. 5 

opEqu  i  pment - opNet wor k 

13 

A. 4. 3. 6 

network-opNetwork-1 

14 

A. 4. 3. 6 

network-opNetwork-2 

15 

A. 4. 3. 6 

opNetwork-root 

16 

A. 4, 3. 8 

t ransport Connect! on- coT ransportProtoco I LayerEntity 

17 

B.2.4  Attribute  Object  Identifiers 

The  following  object  Identifiers  are  assigned  under  the  {  x-attribute  }  node: 


Table  8.5  -  Object  identifiers  assigned  under  "x-attribute"  node 


Reference 

Identifier 

Value 

A. 4. 4.1 

ac t  i  veConnect  i  ons 

1 

A. 4, 4. 2 

address ingSize 

2 

A. 4. 4. 3 

checksumPDUsD  i  scardedCounter 

3 

A. 4. 4. 4 

computerSystemId 

4 

A, 4. 4. 5 

ClNetworkProtocolLayerEnti  tyld 

5 

A. 4. 4. 6 

CoTransportProtocolLayerEnti tyld 

6 

A. 4. 4. 7 

contactList 

7 
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Reference 

loentitier 

Value 

A. 4. A. 8 

contactName 

8 

A. 4. 4. 9 

cpuType 

9 

A. 4. 4. 10 

cpuUti I ization 

10 

A. 4, 4. 11 

customerList 

11 

A, 4. 4. 12 

customerName 

12 

A. 4. 4. 13 

endianess 

13 

A. 4. 4. 14 

functionList 

14 

A. 4. 4. 15 

f unctionName 

15 

A. 4. 4. 16 

inactivityTime 

16 

A. 4. 4. 17 

i  nac  t  i  V  i  tyT  i  tneout 

17 

A. 4. 4. 18 

I  oca  I NetworkAddress 

18 

A, 4. 4. 19 

localNetworkAddresses 

19 

A. 4. 4. 20 

I  oca  I T  ransportAddresses 

20 

A. 4. 4. 21 

I  oca  I T  ranspor t Connec  t  i  onEndpo  i  nt 

21 

A. 4. 4. 22 

locationPointer 

22 

A. 4. 4. 23 

manuf acturerList 

23 

A. 4. 4. 24 

manuf acturerName 

24 

A. 4. 4. 25 

maxConnections 

25 

A. 4. 4. 26 

maxPDUSize 

26 

A. 4. 4. 27 

maxRet  ransmi  ss  i  ons 

27 

A. 4. 4. 28 

memorySize 

28 

A. 4. 4. 29 

memoryUti I ization 

29 

A. 4. 4. 30 

networkEnt  i  tyType 

30 

A. 4. 4. 31 

network! i tie 

A. 4. 4. 32 

npduTimeToLive 

32 

A. 4. 4. 33 

opEquipmentList 

33 

A. 4. 4. 34 

opNetMorkList 

34 

A. 4. 4. 35 

opNetMorkName 

35 

A. 4. 4. 36 

osinf 0 

36 

A. 4. 4. 37 

pdusForwardedCounter 

37 

A. 4. 4. 38 

pdusReasmbldOkCounter 

38 

A. 4. 4. 39 

pdusReasmbldFai ICounter 

39 

93 


PART  18:  Network  Management 


December  1992  (Stable) 


Reference 

Identifier 

Value 

A. 4. 4. 40 

pdusO  i  scardedCounter 

40 

A. 4. 4. 41 

peripheral  List 

41 

A. 4. 4. 42 

peripheral Name 

42 

A. 4. 4. 43 

process  i  ngEnt  t  tyL  i  st 

43 

A. 4. 4. 44 

process  i  ngEnt  i  tyName 

44 

A. 4. 4. 45 

productLabel 

45 

A. 4. 4. 46 

remoteNetworkAddress 

46 

remote! ranspor tConnec  t  i  onEndpo  i  nt 

47 

A. 4. 4. 48 

ret  ransmi  ss  i  onT  i  me 

48 

A. 4. 4. 49 

retransmissionTimerlnitialValue 

49 

A. 4. 4. 50 

serialNumber 

50 

A. 4. 4. 51 

serviceList 

51 

A. 4, 4, 52 

serviceName 

52 

A. 4. 4. 53 

sof twareList 

53 

A. 4. 4. 54 

sof twareName 

54 

A. 4. 4. 55 

system! i me 

55 

A. 4. 4. 56 

transportConnect  ionld 

56 

A. 4. 4. 57 

t ranspor tConnectionReference 

57 

A. 4. 4. 58 

transportEnt i  ty!ype 

58 

A. 4. 4. 59 

type!ext 

59 

A. 4. 4. 60 

up! i  me 

60 

A. 4. 4. 61 

vendorList 

61 

B.2.5  Action  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-action  }  node: 


Table  B.6  -  Object  identifiers  assigned  under  "x-action"  node 


Reference 

Identifier 

Value 

A, 4. 5.1 

activate 

1 

A. 4. 5. 2 

deactivate 

2 
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B.2.6  Parameter  Object  Identifiers 

The  following  object  Identifiers  are  assigned  under  the  {  x-parameter  }  node: 

Table  B.7  -  Object  identifiers  assigned  under  "x-parameter"  node 


Reference 

Identifier 

Value 

A. 4. 6.1 

t  ransportD  i  sconnec  t Cause 

1 

B.2.7  Response  Code  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-responseCode  }  node: 

Table  8.8  -  Object  identifiers  assigned  under  "x-responseCode"  node 


Reference 

Identifier 

Value 

A. 4. 7 

fai lureResponse 

1 

A. 4. 7 

successResponse 

2 

B.2.8  Module  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-module  }  node: 

Table  B.9  -  Object  identifiers  assigned  under  "x-module"  node 


Reference 

Identifier 

Value 

A. 4. 7 

SYNTAX- 1 

1 

B.3  Phase  1  MIL  Object  Identifiers 

Phase  1  MIL  Object  Identifiers  are  assigned  under  the  "nmsig"  node  as  follows: 


oplLibraryVol2  OBJECT  IDENTIFIER 

y-module  OBJECT  IDENTIFIER 

y-objectClass  OBJECT  IDENTIFIER 

y-package  OBJECT  IDENTIFIER 

y-nameBinding  OBJECT  IDENTIFIER 

y-attribute  OBJECT  IDENTIFIER 

y-attributeGroup  OBJECT  IDENTIFIER 

y-parameter  OBJECT  IDENTIFIER 

y-action  OBJECT  IDENTIFIER 

y-notification  OBJECT  IDENTIFIER 


{  nmsig 
{  opILi 
<:  opILi 
{  opiLi 
{  opILi 
{  opiLi 
{  opILi 
{  opILi 
C  opILi 
C  opiLi 


1  > 
braryVol2 
braryVolZ 
braryVol2 
braryVolZ 
braryVolZ 
braryVol2 
braryVol2 
braryVol2 


braryVol2  8 


B.3.1  Object  Class  Object  Identifiers 
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The  following  object  identifiers  are  assigned  under  the  {  y-objectClass  >  node: 

Table  B.10  -  Object  identifiers  assigned  under  "y-objectClass"  node 


Reference 

Identifier 

Value 

A. 5. 1.1 

t  ransportConnect  i  onl VMO 

1 

A. 5. 1.2 

t  ranspor t Connec  t  i  onRet  ransmi  ss  i  onl VMO 

3  [See  note 
below] 

Note:  [Previous  version  (value  2)  has  been  deprecated  in  favor  of  this  version  (value  3).] 
B.3.2  Name  Bindings  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  y-nameBinding  }  node: 


Table  B.11  -  Object  identifiers  assigned  under  "y-nameBinding"  node 


Reference 

Identifier 

Value 

A. 5. 2.1 

t ranspor t Connect  ion I VMO- coT ranspor t Protocol LayerEnti  ty 

1 

A. 5. 2. 2 

transportConnect ionRet ransmi ss ion I VMO- 
coTransportProtocolLayerEnti  ty 

2 

B.3.3  Attribute  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  y-attribute  }  node: 

Table  B.12  -  Object  identifiers  assigned  under  "y-attribute"  node 


Reference 

Identifier 

Value 

A. 5. 3.1 

t  ransportConnect  i  onl VMOI d 

1 

B.3.4  Module  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  y-module  }  node: 

Table  B.13  -  Object  identifiers  assigned  under  "y-module"  node 

Reference 

Identifier 

Value 

A. 5. 4 

SYNTAX-2 

1 
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Annex  C  (informative) 


MOCS  Proforma 

C.1  Introduction 

The  purpose  of  this  MOCS  proforma  is  to  provide  a  mechanism  for  a  supplier  of  an  inplementation  of  these 
agreements  which  claims  conformance  to  a  managed  object  class  to  provide  conformance  information  in  a 
standard  form. 

C.2      Symbols,  abbreviations,  and  terms 

The  MOCS  proforma  contained  in  this  Annex  is  comprised  of  information  in  a  tabular  format  in  accordance  with 
the  guidelines  presented  in  ISO/IEC  96A6-2  [ATSS]  and  ISO/IEC  10165-6  [MICS]. 

The  following  common  notations,  defined  in  ISO/IEC  9646-2,  are  used  for  the  status  column. 

c  conditional 
m  mandatory 
0  opt  i  ona I 

X  prohibited 

not  applicable 

The  following  common  notations,  defined  in  ISO/IEC  9646-2,  are  used  for  the  support  column. 

Ig  the  item  is  ignored  (i.e.,  processed  syntactically  but  not  semantically) 

N  not  implemented 

Y  implemented 

not  applicable 

C.3      Instructions  for  completing  the  MOCS  proforma  to  produce  a  MOCS 

The  supplier  of  the  implementation  shall  enter  an  explicit  statement  in  each  of  the  boxes  provided  using  the 
notation  described  in  clause  C.2.    Additional  instructions  are  provided  in  ISO/IEC  10165-6,  Annex  B. 

0.4      Statements  of  Conformance  to  Managed  Object  Classes 


This  clause  contains  a  MOCS  Proforma  for  each  managed  object  class  defined  in  Annex  A  of  these  agreements, 
and  registered  by  Annex  B  of  these  agreements. 

0.4. 1    Computer  System  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol.  1":computerSystem 

{  1  3  14  2  2  1  1  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 
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Table  C.4.1.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 

Value  of  Object 

Superior  Object 

Stat 

Suppo 

Status 

Supper 

Mditiona 

Label 

Identifier  for 

Class  Template 

us 

rt 

t 

I 

Mame  Binding 

Label 

c 

d 

c 

d 

Informati 

r 

e 

r 

e 

on 

e 

I 

e 

I 

a 

e 

a 

e 

t 

t 

t 

t 

e 

e 

e 

e 

C. 4. 1.1.1 

computerSystem- system 

C  1  3  U  2  2  3  1 

"Rec.  X.721  1 

0 

nt 

m 

> 

ISO/IEC  10165-2  : 

1992": system 

C.A.I. 1.2 

computerSystem-opNetwork 

C  1  3  14  2  2  3  2 
) 

opNetwork 

0 

in 

m 

C.4.1.1. 3 

computerSystem- 

{  1  3  14  2  2  3  3 

computerSystem 

0 

n 

m 

computerSystem 

> 
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Table  C.4.1.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Addi  tional 
Informatio 
n 

s 
e 
t 
b 

y 

c 
r 
e 

3 
t 

e 

g 
e 
t 

r 
e 

P 
I 
a 

C 

e 

a 
d 
d 

r 

e 

tn 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 

Q 

u 
I 
t 

s 
e 
t 
b 

y 

c 
r 
e 

Q 

t 

e 

9 
e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 

ID 
0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 

u 
I 
t 

C, 4. 1.2.1 

peripheralName 

{  1  3  14  2  2  4  42 

> 

c3 

c3 

c3 

X 

X 

X 

C.4.1.2. 2 

peripheralList 

{  1  3  14  2  2  4  41 
) 

c4 

c4 

c4 

c4 

c4 

X 

C.4.1.2. 3 

process ingEnti  tyName 

{  1  3  14  2  2  4  44 
> 

c5 

c5 

c5 

X 

X 

X 

C.4.1.2. 4 

process! ngEnt  i  tyL  i  st 

{  1  3  14  2  2  4  43 
> 

c6 

c6 

c6 

c6 

c6 

X 

C.4.1.2. 5 

systemTime 

{  1  3  14  2  2  4  55 
> 

X 

cO 

X 

X 

X 

X 

C.4.1.2. 6 

upT  i  me 

<:  1  3  14  2  2  4  60 
> 

X 

cO 

X 

X 

X 

X 

C.4.1.2. 7 

"Rec.  M.3100  : 
1992":userLabel 

{  0  0  13  3100  0  7 
50  > 

cO 

cO 

cO 

X 

X 

X 

C. 4. 1 .2.8 

"Rec.  X.^ZI    1  ISO/IEC 
10165-2  :  1992": 

X 

c7 

X 

X 

X 

X 

C.4.1.2. 9 

"Rec.  X.721   1  ISO/IEC 
10165-2  :  1992": 
operat  i  ona I  State 

(29327  35} 

X 

m 

X 

X 

X 

X 

C.4.1.2. 10 

"Rec.  X.721   1  ISO/IEC 
10165-2  :  1992": 
administrati veState 

{29327  31  } 

m 

m 

m 

X 

X 

X 

C.4.1.2. 11 

"Rec.  X.721   I  ISO/IEC 
10165-2  :  1992": 
alarmStatus 

(  2  9  3  2  7  32  } 

m 

m 

m 

m 

m 

X 

C.4.1.2. 12 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
avai labi I i  tyStatus 

{29327  33  } 

X 

m 

X 

X 

X 

X 

C.4.1.2. 13 

computerSysteml d 

{  1  3  14  2  2  4  4 
} 

m 

m 

X 

X 

X 

X 

C.4.1.2. 14 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
a  I lomorphs 

{  2  9  3  2  7  50  } 

c1 

Cl 

X 

X 

X 

X 

C.4.1.2. 15 

"Rec.  X.721   1  ISO/IEC 
10165-2  :  1992": 
nameBinding 

{29327  63  } 

m 

m 

X 

X 

X 

X 

C.4.1.2. 16 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
objectClass 

{29327  65  } 

m 

m 

X 

X 

X 

X 

C.4.1.2. 17 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
packages 

{  2  9  3  2  7  66  } 

c2 

c2 

X 

X 

X 

X 

cO  =  m  if  an  instance  supports  it,  else  - 

cl  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else 
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c3  = 
c4  = 
c5  = 
c6  = 
c7  = 


f  an  instance  supports  it  and  the  peripheralListPkg  is  NOT  present,  else  x 

f  an  instance  supports  it  and  the  peripheralNamePkg  is  NOT  present,  else  x 

f  an  instance  supports  it  and  the  process ingEntityListPkg  is  NOT  present,  else  x 

f  an  instance  supports  it  and  the  process ingEntityNamePkg  is  NOT  present,  else  x 

if  a  resource  can  detect  usage,  else  - 
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Table  C.4.1.3  -  Attribute  Group  Support 


lllndex 

Attribute  Group  Template  Label 

Value  of  Object 

Status 

Suppor 

Additional  Information  || 

Identifier  for 

t 

Attribute  Group 

9 

s 

9 

s 

e 

e 

e 

e 

t 

t 

t 

t 

t 

t 

0 

0 

d 

d 

e 

e 

f 

f 

a 

a 

u 

u 

I 

I 

t 

t 

"Rec.  X.721  1  ISO/IEC  10165-2  : 

C  2  9  3  2  8  1  ) 

m 

X 

|C.4. 1.3.1 

1992":state 
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Table  C.4.1.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
With  Field 

Stat 
us 

Suppo 
rt 

Addition 
al 

Informat 
ion 

c 

0 

n 
f 

n 

0 

n 

C. 4. 1.5.1 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
attributeValueC 
hange 

(  2  9  3  2 
10  1  > 

m 

C.4.1 
.5.1. 
1 

addi  t  ional Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.1 
.5.1. 

2 

addi  t  i  onalText 

{  2  9  3  2  7 
7  > 

0 

C.4.1 
.5.1. 

3 

attributeldent 
i  f ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.1 
.5.1. 

4 

at t r  i  buteVa I ue 
ChangeDef initi 
on 

{  2  9  3  2  7 
10  } 

m 

C.4.1 
.5.1. 

5 

cornel atedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 

C.4.1 
.5.1. 

6 

not"  i  f  1  f^Pi  t"  i  nn  I H 

entif ier 

{  2  9  3  2  7 
16  > 

Q 

.5.1. 

7 

cm  t rr'O  T  nri i  n 

r 

f  ?  9  3  ?  7 
26  > 

C.4.1.5. 2 

"Rec.  X.721  ] 
ISO/IEC  10165-2 
:  1992": 
objectCreation 

{  2  9  3  2 
10  6  > 

m 

C.4.1 
.5.2. 

1 

aHHi  t  i  ariei  1 1  nf  o 
rmation 

{  2  9  3  2  7 
6  > 

Q 

C.4.1 
.5.2. 

2 

ddd  i  t  i  ona I Tsxt 

{  2  9  3  2  7 
7  > 

0 

C.4.1 
.5.2. 

3 

At't'rihiit'^l  icl" 

f  ?  9  3  ?  7 
9  ) 

Q 

C.4.1 
.5.2. 

4 

correlatedNot i 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

.5.2. 

5 

not  y  f  1  i  nr^TH 
liULl  1  IL'aLIUIIlU 

entif ier 

f  ?  0  ?  7 
\.  c  y  J  c  1 

16  } 

0 

L.H.I 

.5.2. 

6 

sourcel ndi  cato 
r 

f    0   Q   T    0  7 

v.  t  y  J  t  f 
26  > 

0 

"Bor     Y   7P1  ' 
KcC •    A . f  C 1  j 

ISO/IEC  10165-2 
:  1992": 
objectDeletion 

/■  ?  0  ? 
10  7  > 

.5.3. 
1 

aH(H  1^1  1  T  r\Ti^ 
a\J\j  1  I  1  Ul  Id  I  1 1 1  i  U 

rmation 

f  ?  0  3  ?  7 
6  > 

0 

C.4.1 
.5.3. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.1 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.1 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.1 
.5.3. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 
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|lndex 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
□ID  Of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Addition 
al 

Infomat 
ion 

c 

0 

n 
f 

n 

0 

n 

C.4.1 
.5.3. 

6 

sourcelndicato 
r 

{29327 
26  > 

0 

C.4. 1.5.4 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
stateChange 

C  2  9  3  2 
10  14  > 

m 

C.4.1 
.5.4. 
1 

additional  Info 
rmat  i  on 

{  2  9  3  2  7 
6  > 

0 

C.4.1 
.5.4. 

2 

additional Text 

{  2  9  3  2  7 
7  > 

0 

C.4.1 
.5.4. 
3 

attributeldent 
if ierList 

{29327 
8  > 

0 

C.4.1 
.5.4. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.1 
.5.4. 

5 

notif icationid 
entif ier 

{29327 
16  > 

0 

C.4.1 
.5.4. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  } 

0 

C.4.1 
.5.4. 
7 

stateChangeOef 
i nit  ion 

{  2  9  3  2  7 
28  > 

m 

C.4.1.5.5 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
processingError 
Alarm 

{  2  9  3  2 
10  10  > 

m 

C.4.1 
.5.5. 
1 

additional  Info 
rmat ion 

{  2  9  3  2  7 
6  > 

0 

C.4.1 
.5.5. 

2 

additional Text 

{  2  9  3  2  7 
7  ) 

0 

C.4.1 
.5.5. 
3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.1 
.5.5. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.1 
.5.5. 

5 

correlatedNoti 
fi cat  ions 

{29327 
12  } 

0 

C.4.1 
.5.5. 

6 

not  i  f  i  cat  i  onid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

L>  .  H  .  1 

.5.5. 

7 

ity 

{  2  9  3  2  7 
17  > 

m 

C.4.1 
.5.5. 
8 

probableCause 

{  2  9  3  2  7 
18  > 

m 

C.4.1 
.5.5. 

9 

proposedRepair 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.1 
.5.5. 

10 

specif icP rob I e 
ms 

{  2  9  3  2  7 
27  > 

0 

C.4.1 
.5.5. 

11 

StateChangeOef 
inition 

{  2  9  3  2  7 
28  > 

0 
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Index 

Not  i  f  i  cat  i  on 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Not  i  f  i  cat  i  on 
Field  Name 
Label 

I ue  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Addi  t ion 

al 

Informat 
ion 

c 

0 

n 
f 

n 

0 

n 

C.4.1 
.5.5. 

12 

thresholdlnfo 

<:  2  9  3  2  7 
29  ) 

0 

C.4.1 
.5.5. 
13 

trendlndicatio 
n 

C  2  9  3  2  7 
30  > 

0 

c.4.1. 5. 6 

■""] 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
environmentalAl 
arm 

{  2  9  3  2 
10  3  > 

m 

C.4.1 
.5.6. 

1 

additional  Info 
rmation 

C  2  9  3  2  7 
6  > 

0 

C.4.1 
.5.6. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.1 
.5.6. 
3 

backUpObject 

C  2  9  3  2  7 
41  > 

0 

C.4.1 
.5.6. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  } 

0 

C.4.1 
.5.6. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.1 
.5.6. 

6 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.1 
.5.6. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 
17  ) 

ID 

C.4.1 
.5.6. 

8 

probableCause 

{  2  9  3  2  7 
18  > 

in 

C.4.1 
.5.6. 

9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.1 
.5.6. 

10 

specif icProble 
ms 

{  2  9  3  2  7 
27  > 

0 

C.4.1 
.5.6. 

11 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  > 

0 

C.4.1 
.5.6. 

12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.1 
.5.6. 
13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.1. 5. 7 

"Rec.  X.721  j 
ISO/IEC  10165-2 
:  1992": 
equipmentAlarm 

{  2  9  3  2 
10  4  } 

m 

C.4.1 
.5.7. 

1 

addi  tional Info 
rmation 

{  2  9  3  2  7 
6  ) 

0 

C.4.1 
.5.7. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.1 
.5.7. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.1 
.5.7. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

NotififAfi  nn 

Field  Name 

Value  OT 

OID  of  Attn 

C  t-  a  f- 

d  La  L 
us 

Suppo 
rt 

Addi  t  i  on 
al 

c 

0 

n 
f 

n 

0 

n 

Label 

Type 

assoc  i  ated 
with  Field 

Informat 
i  on 

C.4.1 
.5.7. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.1 
.5.7. 

6 

notif icat ion Id 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.1 
.5.7. 

7 

percei vedSever 
ity 

{  2  9  3  2  7 
17  > 

ID 

C.4.1 
.5.7. 

8 

probableCause 

{  2  9  3  2  7 
18  ) 

m 

C.4.1 
.5.7. 

9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  } 

0 

C.4.1 
.5.7. 

10 

speci  f icProble 
ms 

{  2  9  3  2  7 
27  } 

0 

C.4.1 
.5.7. 
11 

stateChangeDef 
inition 

{  2  9  3  2  7 
28  > 

0 

C.4.1 
.5.7. 

12 

thresholdinf 0 

{  2  9  3  2  7 
29  > 

0 

C.4.1 
.5.7. 

13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.2    Connection  Oriented  Transport  Protocol  Layer  Entity  IVIOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol. 

1 " : coTranspor tProtocol LayerEnt  i  ty 

{  1  3  14  2  2  1  2  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 


Table  C.4.2.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 
Label 

Value  of  Object 
Identifier  for 

Superior  Object 
Class  Template 

Stat 
us 

Suppo 
rt 

Status 

Suppor 
t 

Addi  tiona 
I 

Name  Binding 

Label 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

Informati 
on 

C.4.2. 1.1 

coTransportProtocol Layer 
Enti ty-computerSystem 

{  1  3  14  2  2  3  4 
> 

computerSystem 

0 

X 

X 

C.4.2. 1.2 

coTransportProtocol Layer 
Entity- system 

{  1  3  14  2  2  3  5 
> 

"Rec.  X.721  1 
ISO/IEC  10165-2  : 
1992": system 

0 

X 

X 

C.4.2. 1.3 

coTransportProtocol Layer 
Ent  i  ty-opEqui  pment 

{  1  3  14  2  2  3  6 
> 

opEqui pment 

0 

X 

X 
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Table  C.4.2.2  -  Attribute  Support 


Index 

H 
'■■i 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Additional 
Informatio 
n 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

g 
e 
t 

r 

e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 

d 

e 

T 

a 
u 
I 
t 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

g 
e 

t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 

in 

0 
V 

e 

s 
e 
t 
t 

0 

d 

e 

T 

a 
u 
I 
t 

C.4.2.2. 1 

manufacturerList 

C  1  3  14  2  2  4  23 
> 

c3 

c3 

c3 

c3 

c3 

X 

C.4.2.2. 2 

manufacturerName 

C  1  3  14  2  2  4  24 
> 

c4 

c4 

c4 

X 

x 

X 

C.4.2.2. 3 

productLabel 

<  1  3  14  2  2  4  45 
> 

cO 

cO 

cO 

X 

X 

X 

r  L  7  7  L 

■■Cor   M  '^inn  • 
1992": version 

f  n  n  1''!  '^mn  n  7 
52  > 

cO 

cO 

cO 

X 

X 

X 

c.4.2.2. 5 

cor  i  a  1  Ml  unKAr 

f  1  3  14  2  2  4  50 
> 

cO 

cO 

cO 

X 

X 

X 

C.4.2.2. 6 

<"  1  3  14  2  2  4  59 

> 

cO 

cO 

cO 

X 

X 

X 

C.4.2.2. 7 

upTime 

{  1  3  14  2  2  4  60 
y 

X 

cO 

X 

X 

X 

X 

C.4.2.2. 8 

"Rec.  X.721  1  I  SO/ 1  EC 
lu \oj-c  :  1 yvc  ' : 
incomingProtocolErrorCount 
er 

{  2  9  3  2  7  77  > 

X 

cO 

X 

X 

X 

X 

C.4.2.2. 9 

"Rec.  X.721  i  I  SO/ 1  EC 

10165-2  :  1992": 

outgo  i  ngProtoco I E  r rorCount 

er 

(29327  85} 

X 

cO 

X 

X 

X 

X 

C.4.2.2. 10 

checksumPDUsD  i  scardedCount 
er 

{  1  3  14  2  2  4  3 
> 

X 

cO 

X 

X 

X 

X 

C.4.2.2. 11 

maxPDUSize 

C  1  3  14  2  2  4  26 
> 

c5 

c5 

c5 

X 

X 

X 

C.4.2.2. 12 

"Rec.  X.721  1  I  SO/ 1  EC 
10165-2  :  1992": 
usageState 

{29327  39} 

X 

c6 

X 

X 

X 

X 

C.4.2.2. 13 

t"  rancrv^p  frFnt"  i  t"\/T\/rwa 

LI  al  lo^^UI   LCI  1 L  1  L  ]r  1  7 

f  1  3  1^22^  58 
} 

X 

m 

X 

X 

X 

X 

C.4.2.2. 14 

I  oca  I T  ransport Addresses 

{  1  3  14  2  2  4  20 
} 

X 

m 

X 

X 

X 

X 

C.4.2.2. 15 

ac t i veConnec t i ons 

C  1  3  14  2  2  4  1 
} 

X 

m 

X 

X 

X 

X 

C.4.2.2. 16 

maxConnections 

{  1  3  14  2  2  4  25 
} 

X 

m 

X 

X 

X 

X 

C.4.2.2. 17 

"Rec.  X.721  1  I  SO/ 1  EC 

10165-2  :  1992": 

outgoi  ngConnect  i  onRequests 

Counter 

C  2  9  3  2  7  82  } 

X 

m 

X 

X 

X 

X 

C.4.2.2. 18 

"Rec.  X.721   1  I  SO/ 1  EC 

10165-2  :  1992": 

incomi ngConnect i onRequests 

Counter 

{29327  74  } 

X 

m 

X 

X  Ix 

X 
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IndGX 

Attribute  Template  Label 

1  MO  nf  nKlA^^ 

VCliUC    Ul     wj  civ  L 

Identifier  for 
Attribute 

Status 

Support 

Addi tionai 
Informatio 
n 

s 
e 
t 
b 

y 

r 
e 
a 
t 
e 

g 
e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
a 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 
a 
e 
f 
a 

y 
I 
t 

s 
e 
t 
b 

y 

c 
r 
e 
a 

e 

g 

e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 

Tl 
0 
V 

e 

s 
e 
t 
t 

0 

a 

e 
f 

a 
u 

I 
t 

C.4.2.2.19 

"Rec.  X.721  1  ISO/IEC 

10165-2  :  1992": 

out  go  i  ngConnec  t  i  onRe  j  ec  t E  r 

rorCounter 

C29327  81  > 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 20 

"Rec.  X.721  j  ISO/IEC 

10165-2  :  1992": 

i  ncomi  ngConnec  t  i  onR e  j  ec  t  E  r 

rorCounter 

{2  9  3  2  7  73} 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 21 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
outgoingDisconnectErrorCou 
nter 

{29327  84  } 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 22 

"Rec.  X.721  j  ISO/IEC 

10165-2  :  1992": 

i  ncomi  ngD  i  sconnec tE  rrorCou 

nter 

{2  9  3  2  7  76  } 

X 

m 

X 

X 

X 

X 

C.4.2.2.23 

"Rec.  X.721  1  ISO/IEC 

10165-2  :  1992": 

outgoi  ngD  i  sconnectCount er 

{29327  83  > 

X 

m 

X 

X 

X 

X 

C.4.2.2.24 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
incomingDisconnectCounter 

{2  9  3  2  7  75  ) 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 25 

"Rec.  X.721   j  ISO/IEC 
10165-2  :  1992": 
octetsSent Counter 

{29327  80} 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 26 

"Rec.  X.721  j  ISO/IEC 

iniA'>-7   •  1007II- 
1  \J  1  Oj    c    .     1  ttC  • 

octetsReceivedCounter 

{29327  78  } 

X 

m 

X 

X 

X 

X 

C.4.2.2.27 

"Rec.  X.721  1  ISO/IEC 
10165-2  •  1992"- 
operational  State 

{29327  35} 

X 

m 

X 

X 

X 

X 

C. 4. 2. 2. 28 

"Rec.  X.721  1  ISO/IEC 
10165-2  •  1992"- 
administrativeState 

{29327  31  } 

m 

m 

m 

X 

X 

X 

C. 4. 2. 2. 29 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
alarmStatus 

{29327  32} 

m 

m 

tn 

m 

m 

X 

C. 4. 2. 2. 30 

coTransportProtocol Layer  Id 

{  1  3  14  2  2  4  6 
} 

m 

m 

X 

X 

X 

X 

C. 4. 2. 2. 31 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
al lomorphs 

{29327  50} 

c1 

Cl 

X 

X 

X 

X 

C. 4. 2. 2. 32 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
nameBinding 

{29327  63} 

m 

m 

X 

X 

X 

X 

C.4.2.2.33 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
objectClass 

{  2  9  3  2  7  65  } 

m 

m 

X 

X 

X 

X 

C.4.2.2.34 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
packages 

{  2  9  3  2  7  66  } 

c2 

c2 

X 

X 

X 

X 
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cO  =  m  if  an  instance  supports  it,  else  - 

c1  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else  - 

c3  =  m  if  an  instance  supports  it  and  the  manufacturerNamePkg  is  NOT  present,  else  x 

c4  =  m  if  an  instance  supports  it  and  the  manufacturerListPkg  is  NOT  present,  else  x 

c5  =  m  if  the  "OPI  Library  Vol.  2  :  1992":transportConnectionIVM0  object  class  is  not  used  to 

provide  this  initial  value,  else  x 

c6  =  m  if  resource  can  detect  usage,  else  - 


Table  C.4.2.3  -  Attribute  Group  Support 


Index 

Attribute  Group  Template  Label 

Value  of  Object 

Status 

Suppor 

Additional  Information 

Identifier  for 

t 

Attribute  Group 

9 

s 

9 

s 

e 

e 

e 

e 

t 

t 

t 

t 

t 

t 

0 

0 

d 

d 

e 

e 

f 

f 

a 

a 

u 

u 

I 

I 

t 

t 

C.4.2.3. 1 

"Rec.  X.721  1  ISO/IEC  10165-2  : 

{  2  9  3  2  8  1  } 

m 

X 

1992":state 
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Table  C.4.2.5  -  Notification  Support 


Index 


Notification 
Type  Label 


Value  of 
Notif icatio 
n  Type 
Identifier 


Stat 
us 


Suppor 
t 


Add 
Info 


Sub-  Notification 
Index  Field  Name  Label 


Value  of 
OID  of  Attr 
Type 

associated 
with  Field 


Stat 
us 


rt 


Suppo  jAddit 
ional 
Infor 
matio 
n 


"Rec.  X.721  I 
ISO/IEC  10165- 
:  1992": 
attributeValueC 
hange 


C.4.2.5. 1 


C.4.2.5. 2 


"Rec.  X.721[ 
ISO/IEC  10165 

1992": 
objectCreation 


210 


2  9  3  2 
1  > 


in  f 


{  2  9  3  2 
6  > 


210 


p. 4. 
5.1 

1 


2|addi  t  i ona 1 1  nf  orrr|{ 
at  ion 


2  9  3  2  7 
6  > 


C.4.2additionalText 
.5.1. 
2 


{  2  9  3  2  7 

7  } 


C.4. 
.5.1. 
B 


2  attributeldentif 
ierList 


{  2  9  3  2  7 
8  > 


C.4.2rattr 
5.1. 

|4 


buteValueCh  { 
angeDef ini  tion 


2  9  3  2 
10  > 


7m 


p. 4 

5.1 

15 


2  correlatedNotif i 
cations 


{  2  9  3  2  7 
12  > 


C.4.2notif icationIden{  2  9  3  2  7 
16  } 


5.1 


t  i  f  i  er 


C.4.2  sourcelndicator 
5.1 

7 


C.4. 
5.2 

1 


2  add  i  t  i  ona  1 1  nf  or(ii|{ 
at  ion 


C.4.2  additionalText 
.5.2. 
2 


C.4.2attributeList 
5.2. 

13 


|C.4. 
5.2 

14 


2 correlatedNotif i 
cations 


C.4 
.5.2 

5 


2  not  i  f  i  cat  i  onl den  { 
t  i  f  i  er 


{  2  9  3  2  7 
26  > 


2  9  3  2  7 
6  ) 


{  2  9  3  2  7 
7  > 


{  2  9  3  2  7 
9  > 


{  2  9  3  2  7 
12  > 


2  9  3  2  7 
16  > 


C.4, 2  sourcelndicator 
.5.2 
16 


{  2  9  3  2  7 
26  > 


C.4. 2. 5.3 


"Rec.  X.721 


T 


ISO/IEC  10165-: 
:  1992": 
objectDeletion 


{  2  9  3  2  |m 
7  > 


210 


C.4 
5.3 

1 


2  additionalInfornn|{ 
at  ion 


2  9  3  2  7 
6  > 


C.4.2 additionalText 
.5.3. 
12 


{  2  9  3  2  7 
7  > 


C.4.2|attributeList 
.5.3. 
13 


{  2  9  3  2  7 
9  > 


C.4 
5.3 

14 


2  correlatedNotif! 
cations 


{  2  9  3  2  7 
12  > 


C.4 
5.3 

5 


2lnotif  icationlden  { 
t  i  f  i  er 


2  9  3  2  7 
16  > 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Not  i  f  i  cat  i  on 
Field  Name  Label 

Value  of 
DID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Addit 
ional 
Infer 
mati  0 
n 

c 

0 

n 
f 

n 

0 

n 

cXI 

.5.3. 

6 

C.4.2 
.5.4. 

1 

sourcelndicator 

{  2  9  3  2  7 
26  ) 

0 

C.4.2. 5. 4 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
stateChange 

{  2  9  3  2 
10  14  > 

m 

addi  tiona I  Inform 
at  ion 

{  2  9  3  2  7 
6  > 

0 



C.4.2 
.5.4. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.2 
.5.4. 

C.4.2 
.5.4. 

attributeldentif 
i  erL  i  st 

{  2  9  3  2  7 
8  > 

0 

correlatedNotif i 
cations 

{  2  9  3  2  7 
12  } 

0 

C.4.2 

.5.4. 

5 

C.4.2 
.5.4. 

6 

notif icationlden 
tif ier 

{  2  9  3  2  7 
16  > 

0 

sourcelndicator 

{  2  9  3  2  7 
26  ) 

0 

C.4.2 
.5.4. 

7 

stateChangeDef in 
i  tion 

{  2  9  3  2  7 
28  > 

m 

C.4.2. 5. 5 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
process ingError 
Alarm 

{  2  9  3  2 
10  10  } 

— 

C.4.2 
.5.5. 
1 

C.4.2 
.5.5. 

2 

addi  tiona I  Inform 
at  ion 

{  2  9  3  2  7 

6  > 

0 

additionalText 

{  2  9  3  2  7 
7  > 

o 

C.4.2 
.5.5. 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.2 

.5.5. 
4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.2 
.5.5. 

5 

correlatedNotif i 
cations 

{  2  9  3  2  7 
12  > 

0 

C.4.2 
.5.5. 

if 

noti  f icationlden 
t  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.2 

.5.5. 

7 

percei vedSever i  t 

y 

{  2  9  3  2  7 

17  } 

ID 

C.4.2 
.5.5. 
8 

probableCause 

{  2  9  3  2  7 
18  > 

m 

C.4.2 
.5.5. 

9 

proposedRepa  i  rAc 
tions 

{  2  9  3  2  7 
19  > 

o 

C.4.2 
.5.5. 
10 

specif icProblems 

(  2  9  3  2  7 

27  > 

0 

C.4.2 
.5.5. 
11 

StateChangeDef in 
it  ion 

{  2  9  3  2  7 
28  } 

0 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 

us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name  Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

SUDDO 

rt 

Addit 
ional 
Infor 
matio 
n 

c 

0 

n 
f 

n 

0 

n 

C.4.2 
.5.5. 
12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.2 
.5.5. 
13 

trendlndication 

{  2  9  3  2  7 
30  } 

0 

C.4.3    ConnectionlessNetwork  Protocol  Layer  Entity  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"OPI  Library  Vol.  1":clNetworkProtocolLayerEntity 

{  1  3  14  2  2  1  3  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 


Table  C.4.3.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 

Value  of  Object 

Superior  Object 

Stat 

Suppo 

Status 

Suppor 

Addition 

Label 

Identifier  for 

Class  Template 

us 

rt 

t 

al 

Name  Binding 

Label 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

Informat 
ion 

C.4.3. 1.1 

clNetworkProtocolLayerEnt 
i  ty-computerSystem 

{  1  3  14  2  2  3  7 
> 

computerSystem 

0 

X 

X 

C.4.3. 1.2 

ClNetworkProtocolLayerEnt 
ity-system 

{  1  3  14  2  2  3  8 
> 

"Rec.  X.721  1 
ISO/IEC  10165-2  : 
1992": system 

0 

X 

X 

C.4.3. 1.3 

c I NetworkProtocol LayerEnt 
i  ty-opEquipment 

{  1  3  14  2  2  3  9 
} 

opEquipment 

0 

X 

X 
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Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 

Status 

Support 

/kdditiona 
I 

Attribute 

s 

9 

r 

s 

s 

g 

r 

a 

r 

8 

Informati 

e 

e 

e 

e 

e 

e 

e 

d 

e 

e 

on 

t 

t 

I 

d 

ID 

t 

t 

t 

P 

d 

fn 

t 

b 

I 

0 

t 

b 

I 

0 

t 

y 

V 

0 

/ 

8 

V 

0 

c 

e 

d 

c 

c 

e 

d 

r 

e 

r 

e 

e 

e 

a 

f 
a 

e 
a 

f 
a 

t 

u 

t 

u 

e 

I 

e 

I 

t 

t 

C. 4. 3. 2. 21 

"Rec.  K.721   |  ISO/IEC 
10165-2  :  1992": 
alarmStatus 

C29327  32> 

m 

IB 

m 

m 

m 

X 

C.4.3.2.22 

c INetworkProtoco I  Layer  I  d 

{13  14  2245} 

m 

m 

X 

X 

X 

X 

C.4.3.2.23 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
al lomorphs 

C29327  50  } 

Cl 

cl 

X 

X 

X 

X 

C. 4. 3. 2. 24 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
nameBinding 

{29327  63} 

m 

m 

X 

X 

X 

C. 4. 3, 2. 25 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
objectClass 

{29327  65  } 

m 

m 

X 

X 

X 

C. 4. 3. 2. 26 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
packages 

{29327  66} 

c2 

c2 

X 

X 

X 

X 

cO  =  m  if  an  instance  supports  it,  else  - 

cl  =  m  if  an  object  supports  al lortnorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else 
c3  =  m  if  an  instance  supports  it  and  the  manuf acturerMamePkg  is  NOT  present,  else  x 
c4  =  m  if  an  instance  supports  it  and  the  manufacturerListPkg  is  MOT  present,  else  x 


ll 
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Table  C.4.3.3  -  Attribute  Group  Support 


Index 

Attribute  Group  Template  Label 

Value  of  Object 

Status 

Suppor 

Additional  Information 

Identifier  for 

t 

Attribute  Group 

g 

s 

9 

s 

5- 

e 

e 

e 

e 

t 

t 

t 

t 

.'5  - 

t 

t 

0 

0 

d 

d 

1                 ■  V.  ^ 

e 

e 

f 

f 

a 

a 

u 

u 

I 

I 

t 

t 

C.4.3.3. 1 

"Rec.  X.721  j  ISO/IEC  10165-2  : 

{  2  9  3  2  8  1  > 

m 

X 

1992":state 

114 


PART  IS:  Network  Management  December  1992  (Stable) 


Table  C.4.3.5  -  Notification  Support 


Index 


Notification 
Type  Label 


Value  of 
Notif icatio 
n  Type 
Identifier 


Stat 
us 


Suppor 

t 

c 

n 

o 

0 

n 

n 

f 

Add 
Info 


Sub- 
Index  Field 


Notification 

Name 
Label 


Value  of 
010  of  AttrRis 
Type 

associated 
with  Field 


Stat  Suppo  Addition 


rt 


T 


:.4.3.5.1 


"Rec.  X.721 


ISO/IEC  10165 

1992": 
attributeValueC 
hange 


{  2  9  3  2 
1  > 


210 


C.4.3.5. 2 


"Rec.  X.721  j 
ISO/IEC  10165-2 

1992": 
objectCreation 


{  2  9  3  2 
10  6  > 


C.4.3.5. 3 


"Rec.  X.721  I 
ISO/IEC  10165- 
:  1992": 
objectDeletion 


{  2  9  3  2 
7  > 


210 


C.4. 
5.1 

1 


3ladditionalInfo 
rmation 


{  2  9  3  2  7 
6  > 


C.4.3additionalText 
.5.1 
2 


{  2  9  3  2  7 
7  > 


C.4. 

5.1 

3 


3attributeldent 
if ierList 


{  2  9  3  2  7 
8  y 


C.4. 
5.1 

|4 


3  attributeValue 
.  ChangeOef initi 
on 


{  2  9  3  2  7|m 
10  > 


C.4 
5.1 

5 


3|correlatedNoti 
fi cat  ions 


{  2  9  3  2  7 
12  > 


C.4. 
5.1 

16 


3  notif icationid 
entif ier 


{  2  9  3  2  7 
16  > 


C.4. 
5.1 

7 


3  sourcelndicato 
r 


{  2  9  3  2  7 
26  > 


C,4 
.5.2 
1 


3additionalInfo 
rmat  i  on 


{  2  9  3  2  7 
6  > 


C.4. 3  additionalText 
5.2 

2 


{  2  9  3  2  7 
7  > 


C.4.3attributeList 
.5.2. 
3 


{  2  9  3  2  7 
9  > 


C.4 
5.2 

4 


3|correlatedNoti 
fi cat  ions 


{  2  9  3  2  7 
12  > 


C.4. 
5.2. 
5 


3|notif  icationid 
ent  i  f  i  er 


{  2  9  3  2  7 
16  > 


C.4. 
5.2 
6 


3  sourcelndicato 
r 


{  2  9  3  2  7 
26  > 


C.4 
.5.3 

1 


3|additionalInfo 
rmation 


{  2  9  3  2  7 
6  > 


C.4. 3  additionalText 
.5.3 

2 


{29327 
7  > 


C.4.3attributeList 
5.3. 

3 


{  2  9  3  2  7 
9  > 


C.4 
.5.3 

14 


3|correlatedNoti 
f  i  cat  i  ons 


{  2  9  3  2  7 
12  > 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
I  dent  i  f  i  er 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Addition 
al 

Informal 
ion 

c 

0 

n 
f 

n 

0 

n 

C.4.3 
.5.3. 

5 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.3 
.5.3. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.3. 5. 4 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
stateChange 

{  2  9  3  2 
10  14  > 

m 

C.4.3 
.5.4. 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.3 
.5.4. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.3 
.5.4. 

3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.3 
.5.4. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  } 

0 

C.4.3 
.5.4. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.3 
.5.4. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  ) 

0 

C.4.3 
.5.4. 

7 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  > 

m 

C.4.3. 5. 5 

!■ 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
processingError 
Alarm 

{  2  9  3  2 
10  10  > 

m 

C.4.3 
.5.5. 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.3 
.5.5. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.3 
.5.5. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.3 
.5.5. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  } 

0 

C.4.3 
.5.5. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.3 
.5.5. 

6 

notif icationid 
ent i  f ier 

{  2  9  3  2  7 
16  > 

0 

C.4.3 
.5.5. 

7 

percei vedSever 
i  ty 

{  2  9  3  2  7 
17  > 

m 

C.4.3 
.5.5. 

8 

probableCause 

{  2  9  3  2  7 
18  > 

m 

C.4.3 
.5.5. 

9 

proposedRepair 
Actions 

{  2  9  3  2  7 
19  } 

0 

C.4.3 
.5.5. 

10 

speci  f icProble 
ms 

{  2  9  3  2  7 
27  > 

0 
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Index 

Notification 
Type  Laisel 

Value  of 
Notif icatio 
n  Type 
laeni i t i er 

Stat 

us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
DID  of  Attn 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
nt 

Addition 
al 

Informat 
ion 

c 

0 

n 
f 

n 

0 

n 

C.4.3 
.5.5. 
11 

stateChangeOef 
i nit  ion 

{  2  9  3  2  7 
28  > 

0 

C.4.3 
.5.5. 
12 

thresholdlnfo 

C  2  9  3  2  7 
29  > 

0 

C.4.3 
.5.5. 
13 

trendlndicatio 
n 

<  2  9  3  2  7 
30  > 

0 

C.4.3.5.6 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
connunicationsA 
I  arm 

C  2  9  3  2 
10  2  > 

m 

C.4.3 
.5.6. 

1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.3 
.5.6. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.3 
.5.6. 
3 

backUpObject 

{  2  9  3  2  7 
41  ) 

0 

C.4.3 
.5.6. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.3 
.5.6. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.3 
.5.6. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.3 
.5.6. 

7 

pence ivedSever 
ity 

{  2  9  3  2  7 
17  > 

m 

C.4.3 
.5.6. 

s 

probableCause 

{  2  9  3  2  7 
18  } 

m 

C.4.3 
.5.6. 

9 

proposedRepair 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.3 
.5.6. 

10 

specif icP noble 

m 

{  2  9  3  2  7 
27  > 

0 

C.4.3 
.5.6. 

11 

StateChangeOef 
inition 

{  2  9  3  2  7 
28  > 

0 

C.4.3 
.5.6. 

12 

thnesholdlnfo 

{  2  9  3  2  7 
29  > 

o 

C.4.3 
.5.6. 

13 

tnendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.4    OMNIPoint  Equipment  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifien  fon  class 

"0P1  Libnany  Vol.  1":opEquipment 

{  1  3  14  2  2  1  4  > 
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Are  all  mandatory  features  of  the  class  supported?  Yes   No  


Table  C.4.4.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 
Laoei 

Value  of  Object 
Identifier  for 
Name  Binding 

Superior  Object 
Class  Template 
Label 

Stat 
us 

Suppo 
rt 

Status 

Suppor 
t 

Addition 
ai 

Informat 
ion 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

C. 4. 4, 1.1 

"Rec.  M.3100  :  1992": 
equ i pment - equ i pment 

C  0  0  13  3100  0 
6  10  > 

"Rec.  M.3100  : 
1992": equipment 

0 

m 

m 

C.4.4.1. 2 

"Rec.  M.3100  :  1992": 
equ  i  pment - ManagedE I ement 

C  0  0  13  3100  0 
6  9  > 

"Rec.  M.3100  : 
1992": 

managedElement 

0 

m 

m 

C.4.4.1. 3 

opEqui pment - 
computerSystem 

C  1  3  14  2  2  3 
10  > 

computerSystem 

0 

m 

m 

C.4.4.1. 4 

opEqu  i  pment - sys  t  em 

{  1  3  14  2  2  3 
11  > 

"Rec.  X.721  1 
ISO/IEC  10165-2  : 
1992": system 

0 

m 

m 

C.4.4.1. 5 

opEqu  i  pment - equ  i  pment 

<  1  3  14  2  2  3 
12  } 

"Rec.  M.3100  : 
1992": equipment 

0 

m 

m 

C.4.4.1. 6 

opEqui pment -opNet work 

{  1  3  14  2  2  3 
13  } 

opNetwork 

0 

m 

m 

I' 


'i 
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Table  C.4.4.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Addi  tiona 
I 

Informati 
on 

s 
e 
t 
b 

y 

c 

r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
I 

a 

c 

e 

a 
fi 
u 

d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 

t 

1. 

s 
e 
t 
b 

y 
c 
r 
e 
a 
t 
e 

g 
e 
t 

r 
e 

P 
I 

a 
c 
e 

a 
d 
d 

r 

e 

[D 

Q 

V 

e 

s 
e 
t 

0 

d 
e 
f 
a 
u 
I 

\ 

C.4.4.2. 1 

"Rec.  M.3100  : 

1992"  •  af  f  ectedOb  iectL  i  <;t 

{  0  0  13  3100  0  7 

X 

cO 

X 

X 

X 

X 

r  A  A  ?  ? 

■<Pe>r   M  '^inn  • 

KcC  .    rl  ■  J  1  UU  ■ 

1992" :  currentProbl  eitiL  i  st 

V    U   U    1 O   3 1 uu   U  f 

17  > 

X 

cO 

X 

X 

X 

X 

r   L   L  P 

1992":locationName 

/  n  n  IX  xinn  n  7 
v  u  u  \j  J  \ uu  U  f 

27  > 

cO 

cO 

cO 

X 

X 

X 

r  L  L  ">  L 

iida/«    m  ^1  nn  • 
Kcc •  n • J  1 uu  • 

1992": replaceable 

V  U  U    1 J  O lUU  u  f 

34  > 

X 

m 

X 

X 

X 

X 

r  A  A  ?  s 

n       .    PI  .  J  1  UU  • 

1992":userLabel 

f  n  n  1"^  "^inn  n  7 

V    U    U     lO   ^lUU    U  ( 

50  > 

cO 

cO 

cO 

X 

X 

X 

r  A  A  7  A 

■■Dor   M  '^inn  • 

KcC  .    PI  .  J  1  uu  . 

1 992" : vendorName 

V  u  U    U  JIUU  U  r 

51  > 

cO 

cO 

cO 

X 

X 

X 

C.4.4.2. 7 

■■Rpc     M  3100  • 
1992": vers ion 

f  0  0  13  3100  0  7 
52  > 

c14 

cl4 

cl4 

X 

X 

X 

r  A  A  7 

/■1'^1A??A7"V 

c5 

c3 

c3 

X 

X 

X 

C.4.4.2.9 

contactName 

C13  14  2248> 

c4 

c4 

c4 

c4 

c4 

X 

C.4.4.2. 10 

customerList 

C  1  3  14  2  2  4  11 
> 

c5 

c5 

c5 

X 

X 

X 

C.4.4.2. 11 

customerName 

{  1  3  14  2  2  4  12 
> 

c6 

c6 

c6 

c6 

c6 

X 

C.4.4.2. 12 

functionList 

t  1  3  14  2  2  4  14 
> 

c7 

c7 

c7 

X 

X 

X 

C.4.4.2. 13 

functionName 

{  1  3  14  2  2  4  15 
> 

c8 

c8 

c8 

c8 

c8 

X 

C.4.4.2. 14 

locationPointer 

{  1  3  14  2  2  4  22 
> 

c9 

c9 

c9 

X 

X 

X 

C.4.4.2. 15 

manufacturerList 

{  1  3  14  2  2  4  23 
> 

clO 

clO 

clO 

X 

X 

X 

C.4.4.2. 16 

manufacturerName 

t  1  3  14  2  2  4  24 
> 

oil 

cll 

cll 

cll 

cll 

X 

C.4.4.2. 17 

opNetworkList 

{1314224  34 
> 

c12 

cl2 

c12 

X 

X 

X 

C.4.4.2. 18 

opNetworkName 

<:  1  3  14  2  2  4  35 
> 

c13 

cl3 

c13 

c13 

c13 

X 

C.4.4.2. 19 

productLabel 

{  1  3  14  2  2  4  45 
> 

cO 

cO 

cO 

X 

X 

X 

C.4.4.2. 20 

serialNunber 

{  1  3  14  2  2  4  50 
> 

cO 

cO 

cO 

X 

X 

X 

C.4.4.2. 21 

serviceList 

C  1  3  14  2  2  4  51 
> 

cl5 

cl5 

c15 

X 

X 

X 

C.4.4.2. 22 

serviceName 

{  1  3  14  2  2  4  52 
> 

cl6 

cl6 

c16 

cl6 

cl6 

X 

C.4.4.2. 23 

softwareList 

{  1  3  14  2  2  4  53 

cl7 

cl7 

cl7 

X 

X 

X 
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I  ndex 

Attribute  Templdte  Label 

value  OT  uDjeci 
Identifier  for 
Attribute 

Status 

Support 

Add  i  t  i  ona 
I 

Informati 
on 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 

m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

C. 4. A. 2. 24 

sof twareName 

{  1  3  14  2  2  4  54 
} 

c18 

c18 

c18 

c18 

c18 

X 

C. 4. 4. 2. 25 

typeText 

{  1  3  14  2  2  4  59 
> 

cO 

cO 

cO 

X 

X 

X 

C. 4. 4, 2. 26 

"Rec.  X.721  j  I  SO/ 1  EC 
10165-2  :  1992": 
usageState 

{29327  39  > 

X 

c19 

X 

X 

X 

X 

C. 4. 4. 2. 27 

vendorList 

{  1  3  14  2  2  4  61 
> 

c20 

c20 

c20 

c20 

c20 

X 

C. 4. 4. 2. 28 

"Rec.  X.721  ]  I  SO/ 1  EC 
10165-2  :  1992": 
operational  State 

(29327  35  > 

X 

m 

X 

X 

X 

X 

C. 4. 4. 2. 29 

"Rec.  X.721  j  I  SO/ 1  EC 
10165-2  :  1992": 
administrat i veState 

{  2  9  3  2  7  31  } 

m 

m 

0(1 

X 

X 

X 

C. 4. 4. 2. 30 

"Rec.  M.3100  : 
1992":alarmStatus 

{  0  0  13  3100  0  7 
6  > 

X 

c 

X 

X 

X 

X 

C. 4. 4. 2. 31 

"Rec.  X.721  1  I  SO/ 1  EC 
10165-2  :  1992": 
avai labi I ityStatus 

{29327  33  } 

X 

m 

X 

X 

X 

X 

C. 4. 4. 2. 32 

"Rec.  M.3100  : 
1992" : equi  pment Id 

{  0  0  13  3100  0  7 
20  } 

m 

m 

X 

X 

X 

X 

C. 4. 4. 2. 33 

"Rec.  X.721  1  I  SO/ 1  EC 
10165-2  :  1992": 
al lomorphs 

{29327  50} 

c1 

c1 

X 

X 

X 

X 

C. 4. 4. 2. 34 

"Rec.  X.721  j  ISO/ 1  EC 
10165-2  :  1992": 
nameBinding 

{29327  63  > 

ID 

m 

X 

X  • 

X 

X 

C. 4. 4. 2. 35 

"Rec.  X.721  1  I  SO/ 1  EC 
10165-2  :  1992": 
objectClass 

{29327  65  } 

ID 

m 

X 

X 

X 

X 

C. 4. 4. 2. 36 

"Rec.  X.721  j  I  SO/ 1  EC 
10165-2  :  1992": 
packages 

{29327  66} 

c2 

c2 

X 

X 

X 

X 
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cO  = 

m 

i 

c1  = 

m 

i 

c2  = 

m 

i 

c3  = 

m 

i 

c4  = 

m 

i 

c5  = 

m 

i 

c6  = 

m 

i 

c7  = 

m 

i 

c8  = 

m 

i 

c9  = 

tn 

i 

c10= 

m 

i 

c11= 

m 

i 

c12= 

m 

i 

c13= 

m 

i 

c14= 

m 

i 

c15= 

m 

1 

c16= 

m 

i 

c17= 

no 

i 

c18= 

m 

i 

c19= 

m 

i 

c20= 

m 

i 

an  instance  supports  it,  else  - 

an  object  supports  al  lornnorphism,  else  - 

any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else  - 

an  instance  supports  it  and  the  contactNamePkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  contactListPkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  customerNamePkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  customerListPkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  functionNamePkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  functionListPkg  is  NOT  present,  else  x 

an  instance  supports  it  and  the  "Rec.  M.3100  :  1992": locationNamePackage  is  NOT  present. 


else  X 


an  instance  supports 
an  instance  supports 
an  instance  supports 
an  instance  supports 
"Rec.  M.3100  :  1992" 
an  instance  supports 
an  instance  supports 
an  instance  supports 
an  instance  supports 
a  resource  can  detect 
an  instance  supports 


it  and  the  manufacturerNamePkg  is  NOT  present,  else  x 
it  and  the  manufacturerListPkg  is  NOT  present,  else  x 
it  and  the  opNetworkNamePkg  is  NOT  present,  else  x 
it  and  the  opNetwcrkListPkg  is  NOT  present,  else  x 
versionPackage  is  also  present  and  if  an  instance  supports  it,  else 
it  and  the  serviceNamePkg  is  NOT  present,  else  x 
it  and  the  serviceListPkg  is  NOT  present,  else  x 
it  and  the  sof twareNamePkg  is  NOT  present,  else  x 
it  and  the  sof twareListPkg  is  NOT  present,  else  x 
usage,  else  - 

it  and  the  "Rec.  M.3100  :  1992": vendor NamePackage  is  NOT  present. 


Table  C.4.4.3  -  Attribute  Group  Support 


Index 

Attribute  Group  Template  Label 

Value  of  Object 

Status 

Suppor 

Additional  Information 

Identifier  for 

t 

Attribute  Group 

g 

s 

g 

s 

e 

e 

e 

e 

t 

t 

t 

t 

t 

t 

0 

0 

d 

d 

e 

e 

f 

f 

a 

a 

u 

u 

I 

I 

t 

t 

C.4.4.3. 1 

"Rec.  X.721  1  ISO/IEC  10165-2  : 

{  2  9  3  2  8  1  } 

m 

X 

1992":state 
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Table  C.4.4.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
I  ndsx 

Notification 

F  i  p  1 H  M  AfHA 

Label 

Value  of 

DID  of  Attr 

Type 

associated 
with  Field 

Stat 

1  IC 

Suppo 

rt 

Additiona 

1 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C. 4, 4. 5.1 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
attributeValue 
Change 

C  2  9  3  2 
10  1  } 

m 

C.4.4 
.5.1. 

1 

additional  Info 
rmat  i  on 

C  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.1. 

2 

additionalText 

(  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.1. 

3 

attributeldent 
if ierList 

(  2  9  3  2  7 
8  > 

0 

C.4.4 
.5.1. 

4 

attributeValue 
ChangeDef initi 
on 

(  2  9  3  2  7 
10  > 

fn 

C.4.4 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

(  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.1. 

6 

notif icationid 
entif ier 

(  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.1. 

7 

sourcelndicato 
r 

(  2  9  3  2  7 
26  > 

0 

C.4.4.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectCreation 

(  2  9  3  2 
10  6  > 

m 

C.4.4 
.5.2. 

1 

additionallnfo 
rmat ion 

(  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.2. 

2 

additionalText 

(  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.2. 

3 

attributeList 

(  2  9  3  2  7 
9  > 

0 

C.4.4 
.5.2. 

4 

correlatedNoti 
fi cat  ions 

(  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.2. 

5 

notif icationid 
ent  i  f  i  er 

(  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.2. 

6 

sourcelndicato 
r 

(  2  9  3  2  7 
26  > 

0 

C.4.4.5. 3 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectDeletion 

{  2  9  3  2 
10  7  > 

m 

C.4.4 
.5.3. 

1 

addi  tional Info 
rmat ion 

(  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.3. 

2 

additionalText 

(  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.3. 
3 

attributeList 

(  2  9  3  2  7 
9  > 

0 

C.4.4 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

(  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.3. 

5 

notif icationid 
entif ier 

(  2  9  3  2  7 
16  } 

o 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Sup 
t 

c 

0 

n 
f 

por 

n 

0 

n 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 

w 1 tn  r 1 eiu 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Informati 
on 

C.4.4 
.5.3. 

6 

sourcelndicato 

r 

{  2  9  3  2  7 
26  > 

0 

C. 4.4. 5. A 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
stateChange 

{  2  9  3  2 
10  14  > 

m 

C.4.4 
.5.4. 

1 

addi  t  ional Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.4. 

2 

addi  t  ional Text 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.4. 

3 

attr ibuteldent 
if ierList 

{  2  9  3  2  7 
8  } 

Q 

C.4.4 
.5.4. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  ) 

0 

C.4.4 
.5.4. 

5 

not  i  f  icat  i  onid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.4. 

6 

sourcel ndi  cato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.4 
.5.4. 

7 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  > 

ID 

C.4.4.5.5 

"Rec.  X.721  I 
ISO/IEC  10165- 
2  :  1992": 
communications 
Alarm 

{  2  9  3  2 
10  2  > 

m 

C.4.4 
.5.5. 
1 

addi  t ional Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.5. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.5. 
3 

bac  kUpOb j  ec  t 

{  2  9  3  2  7 
41  } 

0 

C.4.4 
.5.5. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

r  4  4 
.5.5. 

5 

f icat ions 

{  2  9  3  2  7 
12  > 

Q 

.5.5. 

6 

not  i  f  i  cat  i  onId 
entif ier 

f  O  Q  T  y  7 

v  c  y  J  t  f 
16  > 

0 

C.4.4 
.5.5. 

7 

perce  i  vedSever 
ity 

{  2  9  3  2  7 
17  > 

in 

C.4.4 
.5.5. 
8 

probabl eCause 

{  2  9  3  2  7 
18  } 

fn 

C.4.4 
.5.5. 

9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.4 
.5.5. 
10 

specif icProble 
ms 

{  2  9  3  2  7 
27  ) 

0 

C.4.4 
.5.5. 
1 

StateChangeDef 
inition 

{  2  9  3  2  7 
28  > 

0 
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Index 

Noti  f ication 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Not  i  f  i  cat  i  on 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppc 
rt 

Addttiona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.4 
.5.5. 

t 

thresholdlnfo 

C  2  9  3  2  7 
29  > 

0 

C.4.4 
.5.5. 

trendlndicatio 
n 

{  2  9  3  2  7 
30  } 

0 

C.4.4.5.6 

....  . 

"Rec.  X,721  1 
ISO/IEC  10165- 
2  :  1992": 
process ingErro 
rAlarm 

<  2  9  3  2 
10  10  > 

m 

C.4.4 
.5.5. 
1 

addi  tional Info 
rmat  i  on 

{  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.5. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.5. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.4 
.5.5. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.4 
.5.5. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.5. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.5. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 
17  > 

n 

C.4.4 
.5.5. 

8 

probableCause 

{  2  9  3  2  7 
18  > 

C.4.4 
.5.5. 
9 

proposedRepair 
Actions 

{  2  9  3  2  7 
19  ) 

0 

C.4.4 
.5.5. 

10 

specif icProble 
ms 

{  2  9  3  2  7 
27  > 

0 

C.4.4 
.5.5. 
1 1 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 

28  > 

0 

C.4.4 
.5.5. 

id 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

c.4.4 
.5.5. 
13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.4.5.7 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
envi  ronmentalA 
I  arm 

{  2  9  3  2 
10  3  > 

ID 

C.4.4 
.5.6. 

1 

additional  Info 
rmat ion 

{  2  9  3  2  7 
6  > 

0 

C.4.4 
.5.6. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

o 

C.4.4 
.5.6. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

o 

C.4.4 
.5.6. 

4 

backedUpStatus 

{  2  9  3  2  7 

11  > 

0 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiotta 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.4 
.5.6. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.6. 

6 

notif icationid 
entif ier 

C  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.6. 

7 

perceivedSever 
ity 

C  2  9  3  2  7 
17  > 

m 

C.4.4 
.5.6. 

8 

probableCause 

{  2  9  3  2  7 
18  > 

m 

C,4.4 
.5.6. 

9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.4 
.5.6. 

10 

specif icP rob le 
ms 

{  2  9  3  2  7 
27  > 

0 

C.4.4 
.5.6. 

11 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  > 

0 

C.4.4 
.5.6. 

12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

nil 

.5.6. 

13 

trendind icatio 
n 

y    0    O   "?    0  7 

{.  c  y  5  c  f 
30  > 

0 

C.4.4. 5. 8 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
equipmentAlarm 

C  2  9  3  2 
10  4  > 

m 

C.4.4 
.5.7. 
1 

additional  Info 
rmation 

6  > 

0 

C.4.4 
.5.7. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.4 
.5.7. 

3 

backUpObject 

{  2  y  3  2  f 
41  > 

0 

C.4.4 
.5.7. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.4 
.5.7. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.4 
.5.7. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.4 
.5.7. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 
17  } 

m 

C.4.4 
.5.7. 

8 

probableCause 

{  2  9  3  2  7 
18  > 

m 

C.4.4 
.5.7. 

9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  } 

0 

C.4.4 
.5.7. 

10 

specif icP rob le 
ms 

{  2  9  3  2  7 

27  > 

0 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  TvDe 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attn 
TvDe 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

I nf ormat i 

•  <  I  1         IIIO  V  1 

on 

c 

0 

n 
f 

n 

0 

n 

C.4.4 
.5.7. 
11 

stateChangeDef 
i nit ion 

C  2  9  3  2  7 
28  > 

0 

C.4.4 
.5.7. 

12 

thresholdlnfo 

C  2  9  3  2  7 
29  } 

0 

C.4.4 
.5.7. 

13 

trendlndicatio 
n 

C  2  9  3  2  7 
30  > 

0 

C.4.5    OMNIPoint  Network  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"OPI  Library  Vol.  1":opNetwork 

{  1  3  14  2  2  1  5  ) 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 


Table  C.4.5.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 
Label 

Value  of  Object 
Identifier  for 
Name  Binding 

Superior  Object 
Class  Template 
Label 

Stat 
us 

Suppo 
rt 

Status 

Suppor 
t 

Additiona 
I 

Informati 
on 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

C.4.5. 1.1 

"Rec.  M.3100  :  1992": 
network-network 

(  0  0  13  3100  0 
6  17  } 

"Rec.  M.3100  : 

1992": 

network 

0 

X 

x 

C.4.5. 1.2 

network-opNetwork- 1 

{  1  3  14  2  2  3 
14  > 

"Rec.  M.3100  : 

1992": 

network 

0 

m 

m 

C.4.5. 1.3 

network-opNetwork-2 

{  1  3  14  2  2  3 
15  > 

"Rec.  M.3100  : 

1992": 

network 

0 

m 

m 

C.4.5. 1.4 

opNetwork-root 

{  1  3  14  2  2  3 
16  > 

"Rec.  X.600  j 
I  SO/ 1  EC  9834-1  : 
1992": root 

0 

m 

m 
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Table  C.4.5.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 

Status 

Support 

Addi  t  iona 

Identifier  for 

I 

Attribute 

s 

9 

r 

a 

r 

s 

s 

9 

r 

a 

r 

s 

Informati 

e 

e 

e 

d 

e 

e 

e 

e 

e 

d 

e 

e 

on 

t 

t 

P 

d 

m 

t 

t 

t 

P 

d 

[Tl 

t 

b 

I 

0 

t 

b 

I 

0 

t 

y 

a 

V 

0 

y 

a 

V 

0 

c 

c 

e 

d 

c 

c 

e 

d 

r 

e 

e 

r 

e 

e 

e 

f 

e 

* 

T 

- 

a 

a 

a 

a 

t 

ij 

x. 

u 

e 

I 

Q 

I 

t 

t 

P  A  I  ?  1 

f  n  n  1'^  7inn  n  7 

ID 

m 

X 

X 

X 

7  -V 

J  J 

"Rec.  M.51UU  : 

V  0  U   li  3100  0  ( 

cu 

cu 

cO 

X 

X 

X 

1992":userLabel 

50  } 

c.4.5.2. 3 

network! i tie 

{  1  3  14  2  2  4  31 
> 

ID 

m 

X 

X 

X 

X 

C.4.5.2. 4 

"Rec.  X.721  1  I  SO/ 1  EC 

{:29327  50  > 

Cl 

cl 

X 

X 

X 

X 

10165-2  :  1992": 

al lomorphs 

C.4.5.2. 5 

"Rec.  X.721  j  ISO/ 1  EC 

{  2  9  3  2  7  63  > 

ID 

m 

X 

X 

X 

X 

10165-2  :  1992": 

nameBinding 

C.4.5.2. 6 

"Rec.  X.721  1  I  SO/ 1  EC 

C29327  65  } 

ID 

m 

X 

X 

X 

X 

10165-2  :  1992": 

objectClass 

C.4.5.2. 7 

"Rec,  X,721  1  I  SO/ 1  EC 

<29327  66> 

c2 

c2 

X 

X 

X 

X 

10165-2  :  1992": 

packages 

cO  =  ID  if  an  instance  supports  it,  else  - 

cl  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else 
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Table  C.4.5.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
DID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.5.5. 1 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
attributeValue 
Change 

C  2  9  3  2 
10  1  > 

(D 

C.4.5 
.5.1. 
1 

additional  Info 
rmation 

C  2  9  3  2  7 
6  > 

0 

C.4.5 
.5.1. 

2 

additional  Text 

<  2  9  3  2  7 
7  > 

0 

C.4.5 
.5.1. 

3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.5 
.5.1. 

/ 
H 

attributeValue 
ChangeDef initi 
on 

{  2  9  3  2  7 
10  } 

^ 

C.4.5 
.5.1. 

J 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.5 
.5.1. 

0 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C.4.5 
.5.1. 

7 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.5.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165- 

objectCreation 

C  2  9  3  2 
10  6  > 

m 

C.4.5 
.5.2. 

1 
1 

addi  tional Inf 0 
rmation 

{  2  9  3  2  7 
6  ) 

0 

C.4.5 
.5.2. 

C 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.5 
.5.2. 

attributeList 

{  2  9  3  2  7 
9  } 

0 

C.4.5 
.5.2. 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.5 
.5.2. 

c 
3 

not i  f icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.5 
.5.2. 

o 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.5.5. 3 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectDeletion 

{  2  9  3  2 
10  7  > 

m 

C.4.5 
.5.3. 
1 

additionallnfo 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.5 
.5.3. 

2 

addi tionalText 

{  2  9  3  2  7 
7  } 

0 

C.4.5 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.5 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.5 
.5.3. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  } 

0 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.5 
.5.3. 
6 

sourcelndicato 
r 

(  2  9  3  2  7 
26  > 

0 

C.4.6    Processing  Entity  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol.  1":processingEntity 

{  1  3  U  2  2  1  6  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 


Table  C.4.6.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 
Label 

Value  of  Object 
Identifier  for 

Superior  Object 
Class  Template 

Stat 
us 

Suppo 
rt 

Status 

Suppor 
t 

Addition 
al 

Name  Binding 

Label 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

Informat 
ion 

C.4.6. 1.1 

"Rec.  M.3100  :  1992": 
equ  i  pment - equ  i  pmen t 

C  0  0  13  3100  0 
6  10  } 

"Rec.  M.3100  : 
1992": equipment 

0 

m 

m 

C.4.6. 1.2 

"Rec.  M.3100  :  1992": 
equipment-ManagedE lement 

C  0  0  13  3100  0 
6  9  > 

"Rec.  M.3100  : 
1992": 

managedE lement 

0 

m 

m 

C.4.6. 1.3 

opEqui pment - 
computerSystem 

{  1  3  14  2  2  3 
10  > 

computerSystem 

0 

m 

m 

C.4.6. 1.4 

opEqu  i  pment - sys  t  em 

C  1  3  14  2  2  3 
11  } 

"Rec.  X.721  1 
ISO/IEC  10165-2  : 
1992": system 

0 

m 

m 

C.4.6. 1.5 

opEqui  pment - equ  i  pment 

{  1  3  14  2  2  3 
12  > 

"Rec.  M.3100  : 
1992": equipment 

0 

m 

m 

C.4.6. 1.6 

opEqu  i  pment - opNetwork 

{  1  3  14  2  2  3 
13  > 

opNetwork 

0 

m 

m 
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Table  C.4.6.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Additiona 
I 

Informati 
on 

s 
e 
t 

D 

y 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
1 
I 

a 
c 

e 

a 
d 
d 

r 
e 
m 

0 
V 

Q 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

s 
e 
t 

D 

y 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
1 

a 
e 

a 
d 
d 

r 
e 

0 
V 

Q 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

C.4.6.2. 1 

"Rec.  M.3100  : 
1992":affectedObjectList 

C  0  0  13  3100  0  7 
2  ) 

X 

cO 

X 

X 

X 

X 

C.4.6.2. 2 

"Rec.  M.3100  : 
1992":currentProblemList 

{  0  0  13  3100  0  7 
17  } 

X 

cO 

X 

X 

X 

X 

C.4.6.2. 3 

"Rec.  M.3100  : 
1992":locationName 

{  0  0  13  3100  0  7 
27  } 

cO 

cO 

cO 

X 

X 

X 

C.4.6.2. 4 

"Rec.  M.3100  : 
1992": replaceable 

<:  0  0  13  3100  0  7 
34  > 

X 

tn 

X 

X 

X 

X 

C.4.6.2. 5 

"Rec.  M.3100  : 
1992":userLabel 

C  0  0  13  3100  0  7 
50  > 

cO 

cO 

cO 

X 

X 

X 

C.4.6.2. 6 

"Rec.  M.3100  : 
1 992" : vendorName 

{  0  0  13  3100  0  7 
51  > 

cO 

cO 

cO 

X 

X 

X 

C.4.6.2. 7 

"Rec.  M.3100  : 
1992": vers ion 

(  0  0  13  3100  0  7 
52  ) 

c14 

c14 

c14 

X 

X 

X 

C.4.6.2. 8 

contactList 

<:13  14  2247> 

c3 

c3 

c3 

X 

X 

X 

C.4.6.2. 9 

contactName 

<:13  14  2248} 

c4 

c4 

c4 

c4 

c4 

X 

C.4.6.2. 10 

customerList 

{  1  3  14  2  2  4  11 
> 

c5 

c5 

c5 

X 

X 

X 

C.4.6.2. 11 

customerName 

{  1  3  14  2  2  4  12 
> 

c6 

c6 

c6 

c6 

c6 

X 

C.4.6.2. 12 

functionList 

{  1  3  14  2  2  4  14 
> 

c7 

c7 

c7 

X 

X 

X 

C.4.6.2. 13 

functionName 

{  1  3  14  2  2  4  15 
) 

c8 

c8 

c8 

c8 

c8 

X 

C.4.6.2. 14 

locationPointer 

C  1  3  14  2  2  4  22 
> 

c9 

c9 

c9 

X 

X 

X 

C.4.6.2. 15 

manufacturerList 

{  1  3  14  2  2  4  23 
> 

clO 

clO 

clO 

X 

X 

X 

C.4.6.2. 16 

manufacturerName 

C  1  3  14  2  2  4  24 
> 

c11 

c11 

c11 

c11 

c11 

X 

C.4.6.2. 17 

opNetworkList 

{  1  3  14  2  2  4  34 
> 

c12 

c12 

c12 

X 

X 

X 

C.4.6.2. 18 

opNetworkName 

{  1  3  14  2  2  4  35 
> 

c13 

c13 

c13 

c13 

c13 

X 

C.4.6.2. 19 

productLabel 

{  1  3  14  2  2  4  45 
> 

cO 

cO 

cO 

X 

X 

X 

C.4.6.2. 20 

serialNumber 

{  1  3  14  2  2  4  50 

cO 

cO 

cO 

X 

X 

X 

C.4.6.2. 21 

serviceList 

{  1  3  14  2  2  4  51 
> 

c15 

c15 

c15 

X 

X 

X 

C.4.6.2. 22 

serviceName 

{  1  3  14  2  2  4  52 
> 

c16 

c16 

c16 

c16 

c16 

X 

C.4.6.2. 23 

sof twareList 

{  1  3  14  2  2  4  53 
) 

c17 

c17 

c17 

X 

X 

X 
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Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Addi  tiona 
I 

Informati 
on 

s 
e 
t 
b 
y 

c 
r 

Q 

a 
t 
e 

g 

e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 

d 

e 

a 
u 
I 
t 

s 
e 
t 
b 
/ 
c 
r 

6 

a 
t 
e 

g 

e 
t 

r 
e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 

m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 

T 

a 
u 
I 

t 

C. 4, 6. 2. 24 

sof twareName 

{  1  3  14  2  2  4  54 
> 

c18 

c18 

c18 

c18 

c18 

X 

C. 4. 6. 2. 25 

type! ex t 

C  1  3  14  2  2  4  59 

> 

cO 

cO 

cO 

X 

X 

X 

C. 4. 6. 2. 26 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
usageState 

{29327  39} 

X 

c19 

X 

X 

X 

X 

C. 4. 6. 2. 27 

vendorList 

{  1  3  14  2  2  4  61 
> 

c20 

c20 

c20 

c20 

c20 

X 

0.4.6.2.28 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
operationalState 

{29327  35} 

X 

m 

X 

X 

X 

X 

C. 4. 6. 2. 29 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
administrativeState 

{  2  9  3  2  7  31  > 

m 

m 

m 

X 

X 

X 

C. 4. 6. 2. 30 

"Rec.  M.3100  : 
1992":alarmStatus 

{  0  0  13  3100  0  7 
6  > 

X 

c 

X 

X 

X 

X 

C. 4. 6. 2. 31 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
avai labi I i  tyStatus 

{29327  33  > 

X 

m 

X 

X 

X 

X 

C. 4. 6. 2. 32 

"Rec.  M.3100  : 
1992": equipment  Id 

{  0  0  13  3100  0  7 
20  > 

m 

m 

C. 4. 6. 2. 33 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
al lomorphs 

{29327  50  > 

cl 

cl 

X 

X 

X 

X 

C. 4. 6. 2. 34 

"Rec.  X.721  j  ISO/IEC 
10165-2  :  1992": 
names inding 

{29327  63  } 

m 

m 

X 

X 

X 

X 

C. 4. 6. 2. 35 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
objectClass 

{  2  9  3  2  7  65  } 

m 

m 

X 

X 

X 

X 

C. 4. 6. 2. 36 

"Rpr     X  7?1    '  I^n/IFT 
10165-2  :  1992": 
packsges 

<"2932766} 

c2 

c2 

X 

X 

X 

X 

C. 4. 6. 2. 37 

/■17  1A  2242'> 

X 

c21 

X 

X 

X 

X 

C. 4. 6. 2. 38 

endianess 

{  1  3  14  2  2  4  13 
} 

X 

c21 

X 

X 

X 

X 

C. 4. 6. 2. 39 

cpuUti lization 

{  1  3  14  2  2  4  10 
} 

X 

cO 

X 

X 

X 

X 

C. 4.6. 2. 40 

memorySi  ze 

{  1  3  14  2  2  4  28 
} 

X 

c21 

X 

X 

X 

X 

C. 4. 6. 2. 41 

memoryUti lization 

{  1  3  14  2  2  4  29 
} 

X 

cO 

X 

X 

X 

X 

C. 4. 6. 2. 42 

upT  i  me 

{  1  3  14  2  2  4  60 
} 

X 

cO 

X 

X 

X 

X 

C. 4. 6. 2. 43 

cpuType 

{13  14  2249} 

X 

m 

X 

X 

X 

X 

C. 4. 6. 2. 44 

osinf 0 

{  1  3  14  2  2  4  36 
} 

X 

m 

X 

X 

X 

X 
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else  X 


cO  = 

m 

]  f 

c1  = 

HI 

i  f 

an  obi^ct  suDDorts  al  LorinorDhi<:ni  - 

all   w  J  WW  V    0  wbiA^wi  w  9    a  V  V  wi  iiiw  i  ii^  i  i  iviii  g    w  »  9^ 

c2  = 

m 

i  f 

any  any  registered  package  (other  than  this  package)  has  been  instantiated. 

else  - 

c3  = 

(D 

1  f 

an  instance  supports  it  and  the  contactNamePkg  is  NOT  present,  else  x 

c4  = 

m 

i  f 

an  instance  supports  it  and  the  contactListPkg  is  NOT  present,  else  x 

c5  = 

m 

i  f 

an  instance  supports  it  and  the  customerNamePkg  is  NOT  present,  else  x 

c6  = 

ID 

i  f 

an  instance  supports  it  and  the  customerListPkg  is  NOT  present,  else  x 

c7  = 

m 

an  instance  supports  it  and  the  functionNamePkg  is  NOT  present,  else  x 

c8  = 

m 

if 

an  instance  supports  it  and  the  functionListPkg  is  NOT  present,  else  x 

c9  = 

m 

if 

an  instance  supports  it  and  the  "Rec.  M.3100  :  1992": locationNamePackage  is 

NOT  present. 

c10= 

m 

if 

an  instance  supports  it  and  the  manufacturerNamePkg  is  NOT  present,  else  x 

Cll  = 

m 

if 

an  instance  supports  it  and  the  manufacturerListPkg  is  NOT  present,  else  x 

c12= 

m 

if 

an  instance  supports  it  and  the  opNetworkNamePkg  is  NOT  present,  else  x 

c13= 

m 

if 

an  instance  supports  it  and  the  opNetuorkListPkg  is  NOT  present,  else  x 

cU= 

m 

if 

"Rec.  M.3100  :  1992": vers ionPackage  is  also  present  and  if  an  instance  supports  it,  else  - 

c15= 

m 

if 

an  instance  supports  it  and  the  serviceNamePkg  is  NOT  present,  else  x 

c16= 

m 

if 

an  instance  supports  it  and  the  serviceListPkg  is  NOT  present,  else  x 

c17= 

m 

if 

an  instance  supports  it  and  the  sof twareNamePkg  is  NOT  present,  else  x 

c18= 

m 

if 

an  instance  supports  it  and  the  sof twareListPkg  is  NOT  present,  else  x 

c19= 

m 

if 

a  resource  can  detect  usage,  else  - 

c20= 

ID 

if 

an  instance  supports  it  and  the  "Rec.  M.3100  :  1992":vendorNamePackage  is  NOT  present, 

c21= 

ID 

if 

relevant  to  the  underlying  resource,  else  - 

Table  C.4.6.3  -  Attribute  Group  Support 


Index 

Attribute  Group  Template  Label 

Value  of  Object 

Status 

Suppor 

Additional  Information 

Identifier  for 

t 

Attribute  Group 

9 

s 

9 

s 

e 

e 

e 

e 

t 

t 

t 

t 

t 

t 

0 

0 

d 

d 

e 

e 

f 

f 

a 

a 

u 

u 

I 

I 

t 

t 

C.4.6.3. 1 

"Rec.  X.721  1  ISO/IEC  10165-2  : 

{  2  9  3  2  8  1  } 

m 

X 

1992":state 
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Table  C.4.6.5  -  Notification  Support 


Index 

Notification 
Type  Label 

\/alue  of 
Notif icatio 
n  Type 
Identifier 

Stat 

us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

^ot 1 f  i  cat  i  on 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 

us 

Suppo 
rt 

\dd  i  t  i  ona 
I 

Informati 
on 

z 

0 

n 
f 

n 

0 

n 

C.4.6.5. 1 

"Rec.  X.721  j 
ISO/IEC  10165- 
2  :  1992": 
attributeValue 
Change 

C  2  9  3  2 
10  1  } 

m 

C.4.6 
.5.1. 

1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.6 
.5.1. 

2 

additionalText 

{  2  9  3  2  7 
7  ) 

0 

C.4.6 
.5.1. 

3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.6 
.5.1. 

4 

attributeValue 
ChangeDef initi 
on 

{  2  9  3  2  7 
10  > 

m 

C.4.6 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

o 

C.4.6 
.5.1. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  ) 

0 

C.4.6 
.5.1. 

7 

sourcelndicato 
r 

{  2  9  3  2  7 
26  } 

0 

C.4.6.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectCreation 

{  2  9  3  2 
10  6  > 

m 

C.4.6 
.5.2. 

1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  } 

0 

C.4.6 
.5.2. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.6 
.5.2. 
3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.6 
.5.2. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.6 
.5.2. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.6 
.5.2. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.6,5.3 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectDeletion 

{  2  9  3  2 
10  7  ) 

m 

C.4.6 
.5.3. 

1 

additional  Info 
rmat  ion 

r  0  O  7  ^  7 
\,    C   7   0    C.  1 

6  } 

0 

C.4.6 
.5.3. 

2 

additionalText 

{  2  9  3  2  7 
7  } 

0 

C.4.6 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.6 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.6 
.5.3. 

5 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 
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Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Infomtati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.6 
.5.3. 
6 

sourcelndicato 

{  2  9  3  2  7 
26  > 

0 

C.4.6.5.4 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
stateChange 

>  I 

{  2  9  3  2 
10  14  > 

m 

C.4.6 
.5.4. 

i 

additional  Info 
rmat 1  on 

{  2  9  3  2  7 
6  ■> 

0 

C.4.6 

5  4 

2 

additionalText 

{  2  9  3  2  7 

7  -v 

0 

C.4.6 

3 

attributeldent 

iff  apI  1 
1  T  1  CI  L  1  S>  I 

{  2  9  3  2  7 

ft  "V 

0 

C.4.6 
5  4 

4 

correlatedNoti 

f  1  r'a^  i  Anc 
1  1      L  1  ui  Da 

{  2  9  3  2  7 
12  "> 

0 

C.4.6 
.5.4. 
5 

notif icationid 
6nt  i  f  i  cr 

{  2  9  3  2  7 
16  ■> 

0 

C.4.6 
.5.4. 

6 

sourcelndicato 
p 

{  2  9  3  2  7 
26  > 

0 

C.4.6 
.5.4. 
7 

stateChangeOef 
i  n  i  t  i  on 

{  2  9  3  2  7 
28  > 

nn 

C.4.6.5.5 

"Rec.  X.721  j 
ISO/IEC  10165- 
2  :  1992": 
conmuni cat  ions 
Alarm 

{  2  9  3  2 
10  2  > 

m 

C.4.6 
.5.5. 

1 

additional Info 
rmat  i  on 

{  2  9  3  2  7 
6  > 

0 

C.4.6 
.5.5. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  } 

0 

C.4.6 
3 

backUpObject 

{  2  9  3  2  7 
41  "V 

0 

 — 

C.4.6 

4 

backedUpStatus 

{  2  9  3  2  7 

11  "V 

0 

C.4.6 
.5.5. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 

12  > 

0 

C.4.6 
.5.5. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.6 
.5.5. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 
17  > 

ID 

C.4.6 
.5.5. 
8 

probableCause 

{  2  9  3  2  7 
18  > 

n 

C.4.6 
.5.5. 
9 

proposedRepa  \  r 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.6 
.5.5. 
10 

specif icProble 

ms 

{  2  9  3  2  7 
27  > 

0 

C.4.6 
.5.5. 
11 

StateChangeOef 
inition 

{  2  9  3  2  7 
28  > 

o 
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Type  Label 

Notif icatio 
n  Type 
Identifier 

O  La  L 

us 

Suppor 
t 

Info 

ouu 

Index 

nOL 111 CaL 1  on 

Field  Name 
Label 

value  OT 
DID  of  Attr 
Type 

associated 
with  Field 

C      £k  t- 

us 

Suppo 
rt 

•KyMJ  111  OTUl 

I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.6 
.5.5. 
12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.6 
.5.5. 
13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

c.4.6. 5. 6 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
process ingErro 
rAlarm 

{  2  9  3  2 
10  10  > 

m 

C.4.6 
.5.5. 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.6 
.5.5. 

2 

additionalText 

{  2  9  3  2  7 

7  > 

o 

C.4.6 
.5.5. 
3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.6 
.5.5. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.6 
.5.5. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.6 
.5.5. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.6 
.5.5. 

7 

perceivedSever 
ity 

{  2  9  3  2  7 
17  > 

nn 

C.4.6 
.5.5. 
8 

probableCause 

{  2  9  3  2  7 
18  > 

m 

C.4.6 
.5.5. 

9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.6 
.5.5. 

10 

specif icProble 
ms 

{  2  9  3  2  7 
27  > 

0 

C.4.6 
.5.5. 
11 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  > 

0 

C.4.6 
.5.5. 

12 

thresholdlnfo 

{  2  9  3  2  7 
29  > 

0 

C.4.6 
.5.5. 

13 

trendlndicatio 
n 

{  2  9  3  2  7 
30  > 

0 

C.4.6. 5, 7 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
environmental A 
I  arm 

{  2  9  3  2 
10  3  > 

m 

C.4.6 
.5.6. 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.6 
.5.6. 

2 

additionalText 

{  2  9  3  2  7 
7  } 

0 

C.4.6 
.5.6. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.6 
.5.6. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 
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Index 


Notification 
Type  Label 


Value  of      Stat  Suppor 
Notif  icatiolus  It 
n  Type 
Identifier 


Add 

Info 


jSub-  iNotif ication     lvalue  of 


jlndex Field  Name 
Label 


OID  of  Attn 
Type 

associated 
with  Field 


Stat 
us 


Suppo 
rt 


Additiona 
I 

Informati 
on 


C.4.6 
.5.7. 

11 


stateChangeDef 
i nit  ion 


<:  2  9  3  2  7 
28  > 


C.4.6  thresholdlnfo 

.5.7. 
12 


C.4.6  trendlndicatio 
.5. 7. In 
13 


C  2  9  3  2  7|o 
29  > 


C  2  9  3  2  7|o 
30  > 


C.4.7    Transport  Connection  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol.  1":transportConnection 

{  1  3  14  2  2  1  7  > 

Are  all  mandatory  features  of  the  class  supported?  Yes 

Table  C.4.7.1  -  Name  Binding  Su 


No 


Index 

Name  Binding  Template 

Value  of  Object 

Superior  Object 

Stat 

Suppo 

Status 

Suppor 

Addi  tion 

Label 

Identifier  for 

Class  Template  Label 

us 

rt 

t 

al 

Name  Binding 

c 

d 

c 

d 

Informat 

r 

e 

r 

e 

ion 

e 

I 

e 

I 

a 

e 

a 

e 

t 

t 

t 

t 

e 

e 

e 

e 

C.4.7. 1.1 

transportConnect ion- 

C  1  3  14  2  2  3 

coTransportProtocolL 

0 

X 

m 

coTransportProtocol Layer 

17  > 

ayerEntity 

Entity 
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Table  C.4.7.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 

Status 

Support 

Additiona 
I 

Attribute 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
I 

3 

c 
e 

a 
d 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
I 

3 

c 
e 

a 
d 
d 

r 
e 

m 

0 
V 

e 

s 
e 
t 
t 
o 
d 
e 
f 
a 
u 
I 
t 

Inf ormati 
on 

C.4.7.2. 1 

maxRetransmissions 

{  1  3  14  2  2  4  27 
} 

X 

cO 

X 

X 

X 

X 

c.4.7.2. 2 

ret  ransmi  ss  i  onT  i  me 

TO    /  to 

> 

X 

cO 

X 

X 

X 

X 

C.4.7.2. 3 

retransmissionTimerIni  tialV 
alue 

{  1  3  14  2  2  4  49 
> 

X 

cO 

X 

X 

X 

X 

C.4.7.2. 4 

"Rec.  X.721   1  I  SO/ 1  EC 
10165-2  :  1992": 
pdusRetransmi  ttedErrorCount 
er 

{29327  87  } 

X 

cO 

X 

X 

X 

X 

r  /.  7  ^  R 

iiD          V   7^1    1    1  on  /  1  cf 
Kec .   A  .  / c  1    j    1 oU/ 1 cL 

10165-2  :  1992": 
octetsRetransmi  ttedErrorCou 
nter 

9   O   7         7   70  \ 

X 

cu 

X 

X 

X 

X 

c.4.7.2. 6 

"Rec.  X.721  j  I  SO/ 1 EC 
10165-2  :  1992": 
pdusRetransmi  ttedErrorThres 
hold 

{  2  9  3  2  7  102  > 

X 

cO 

cO 

X 

X 

X 

C.4.7.2. 7 

"Rec.  X.721  1  ISO/IEC 

10165-2  :  1992": 

outgo) ngProtocolErrorCounte 

r 

{29327  85  > 

X 

cO 

X 

X 

X 

X 

c.4.7.2. 8 

checksumPDUsD  i  scardedCounte 
r 

{  1  3  14  2  2  4  3 
> 

X 

cO 

X 

X 

X 

X 

C.4.7.2. 9 

I  oca  I T  ranspor t Connec  t  i  onEnd 
point 

{  1  3  14  2  2  4  21 
> 

X 

m 

X 

X 

X 

X 

C.4.7.2. 10 

remot  eT  ranspor  t  Connec  t  i  onEn 
dpoint 

{  1  3  14  2  2  4  47 
> 

X 

m 

X 

X 

X 

X 

C.4.7.2. 11 

t ranspor t Connec tionReferenc 
e 

{  1  3  14  2  2  4  57 
> 

X 

m 

X 

X 

X 

X 

C.4.7.2. 12 

I  oca  I Networ kAddress 

{  1  3  14  2  2  4  18 
> 

X 

m 

X 

X 

X 

X 

C.4.7.2. 13 

remoteNetworkAddress 

{  1  3  14  2  2  4  46 
> 

X 

m 

X 

X 

X 

X 

C.4.7.2. 14 

i  nact  i  vi  tyT  i  meout 

{  1  3  14  2  2  4  17 
} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 15 

inactivityTime 

{  1  3  14  2  2  4  16 
} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 16 

maxPDUSize 

{  1  3  14  2  2  4  26 
} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 17 

"Rec.  X.721   j  ISO/IEC 
10165-2  :  1992": 
pdusSentCounter 

{29327  88} 

X 

m 

X 

X 

X 

X 

C.4.7.2. 18 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
pdusRecei vedCounter 

{29327  86} 

X 

m 

X 

X 

X 

X 
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lllndex 

(Attribute  Template  Label 

Value  of  Object 
Identifier  for 

Status 

Support 

Additiona 
I 

Attribute 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

9 
e 
t 

r 

e 

P 
I 

a 
c 
e 

a 
d 
d 

r 
e 
m 

0 
V 

e 

s 
e 
t 
t 

0 

d 

e 

T 

a 
u 
I 
t 

s 
e 
t 
b 
/ 

C 

r 
e 
a 
t 
e 

9 
e 
t 

r 
e 

P 
I 
a 

C 

e 

a 
d 
d 

r 
e 

Tl 
0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
t 
a 
ij 
I 
t 

Informati 
on 

C.4.7.2.19 

"Rec.  X.721  1  ISO/lEC 
10165-2  :  1992": 
octetsSentCounter 

{29327  80} 

X 

tn 

X 

X 

X 

X 

C. 4. 7.2. 20 

"Rec.  X.721  I  I  SO/ 1  EC 
10165-2  :  1992": 
octetsReceivedCounter 

C2  9  3  2  7  78  > 

fn 

C. 4. 7.2. 21 

"Rec.  X.721  j  I  SO/ 1  EC 
10165-2  :  1992": 
incomingProtocolErrorCounte 
r 

€29327  77  } 

X 

m 

X 

X 

X 

X 

C. 4. 7. 2. 22 

transportConnectionId 

{  1  3  U  2  2  4  56 
} 

X 

m 

X 

X 

X 

X 

"Rec.  x.fdi  1  ISO/ let 
10165-2  :  1992": 
al  loniorphs 

X 

Cl 

X 

X 

X 

X 

C.4.7.2.24 

"Rec.  X,721  1  ISO/lEC 
10165-2  :  1992": 
nameBinding 

{  2  9  3  2  7  63  } 

X 

m 

X 

X 

X 

X 

C.4.7.2.25 

"Rec.  X.721  1  ISO/lEC 
10165-2  :  1992": 
objectClass 

{29327  65} 

X 

ID 

X 

X 

X 

X 

C.4.7.2.26 

"Rec.  X.721  1  ISO/lEC 
10165-2  :  1992": 
packages 

{  2  9  3  2  7  66  } 

X 

■ 

X 

X 

X 

cO  =  m  if  an  instance  supports  it,  else  - 

cl  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else  - 


139 


PART  18:  Network  Management 


December  1992  (Stable) 


Table  C.4.7.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.7.5. 1 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
attributeValue 
Change 

{  2  9  3  2 
10  1  > 

m 

C.4.7 
.5.1. 
1 

additionallnfo 
rmat  i  on 

{  2  9  3  2  7 
6  > 

0 

C.4.7 
.5.1. 
2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.7 
.5.1. 

3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.7 
.5.1. 

4 

attributeValue 
ChangeDef initi 
on 

{  2  9  3  2  7 
10  > 

C.4.7 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.7 
.5.1. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.7 
.5.1. 

7 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.7.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectCreation 

{  2  9  3  2 
10  6  > 

m 

C.4.7 
.5.2. 

1 

additionallnfo 
rmat ion 

{  2  9  3  2  7 
6  > 

0 

C.4.7 
.5.2. 

2 

additionalText 

{  2  9  3  2  7 
7  } 

0 

C.4.7 
.5.2. 
3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.7 
.5.2. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C,4.7 
.5.2. 

5 

noti  f icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  > 

0 

C,4.7 
.5.2. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  > 

0 

C.4.7.5. 3 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectDeletion 

{  2  9  3  2 
10  7  ) 

m 

C.4,7 
.5.3. 
1 

addi  tional Info 
rmat ion 

{  2  9  3  2  7 
6  } 

0 

C.4.7 
.5.3. 

2 

addi  tional Text 

{  2  9  3  2  7 
7  > 

0 

C.4.7 
.5.3. 
3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.7 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.7 
.5.3. 

5 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2  7 
16  ) 

0 
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Index 

Not  i  f  i  cat  i  on 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 
with  Field 

Stat 
us 

Suppo 
rt 

I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.7 
.5.3. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  } 

0 

C. 4. 7.5. 4 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
conmuni cat  ions 
Alarm 

C  2  9  3  2 
10  2  > 

cO 

C.4.7 
.5.4. 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  } 

0 

C.4.7 
.5.4. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.7 
.5.4. 

3 

backUpObject 

{  2  9  3  2  7 
41  > 

0 

C.4.7 
.5.4. 

4 

backedUpStatus 

{  2  9  3  2  7 
11  > 

0 

C.4.7 
.5.4. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2  7 
12  > 

0 

C.4.7 
.5.4. 

6 

notif icationid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.7 
.5.4. 

7 

percei vedSever 
ity 

{  2  9  3  2  7 
17  > 

n\ 

C.4.7 
.5.4. 

8 

probableCause 

{  2  9  3  2  7 
18  } 

T\ 

C.4.7 
.5.4. 
9 

proposedRepai  r 
Actions 

{  2  9  3  2  7 
19  > 

0 

C.4.7 
.5.4. 

10 

specif icP rob le 
ms 

{  2  9  3  2  7 
27  > 

0 

C.4.7 
.5.4. 

11 

stateChangeDef 
i nit  ion 

{  2  9  3  2  7 
28  > 

0 

C.4.7 
.5.4. 
12 

thresholdinf 0 

{  2  9  3  2  7 
29  > 

0 

C.4.7 
.5.4. 

13 

t rend I nd icatio 
n 

{  2  9  3  2  7 
30  > 

0 

cO  =  m  if  instance  supports  it,  else  - 

C.4.8    Transport  Connection  IVMO  MOCS  Proforma 


Managed  Object  class  teinplate  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol.  2":transportConnectionIVM0 

{  1  3  14  2  1  1  1  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 
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Table  C.4.8.1  -  Name  Binding  Support 


Index 

Name  Binding  Template 

Value  of  Object 

Superior  Object 

Stat 

Suppo 

Status 

Supper 

(Addition 

Label 

Identifier  for 

Class  Template  Label 

us 

rt 

t 

Bl 

Name  Binding 

c 

d 

c 

d 

Informat 

r 

e 

r 

e 

ion 

e 

I 

e 

I 

a 

e 

a 

e 

t 

t 

t 

t 

e 

e 

e 

e 

C. A. 8. 1.1 

t ransportConnect  i  onl VMO- 

C  1  3  U  2  1  3  1 

"0P1  Library  Vol. 

0 

X 

X 

coTransportProtocol Layer 

> 

1": 

Entity 

coTransportProtocolL 

ayerEnt  i  ty 
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Table  C.4.8.2  -  Attribute  Support 


I 

Attribute  T^nmtatp  1  aK^I 

Status 

Support 

1      .  .  .1 
Add 1 t 1 ona 

Identifier  for 

I 

Attribute 

s 

9 

r 

a 

r 

s 

s 

9 

r 

a 

r 

s 

Informati 

e 

e 

e 

d 

e 

e 

e 

e 

e 

d 

e 

e 

on 

t 

t 

P 

d 

m 

t 

t 

t 

p 

d 

m 

t 

b 

I 

0 

t 

b 

I 

0 

t 

y 

a 

V 

0 

y 

a 

V 

0 

c 

c 

e 

d 

c 

c 

e 

d 

r 

e 

e 

r 

e 

e 

e 

f 

e 

f 

a 

a 

a 

a 

t 

u 

t 

u 

e 

[ 

e 

[ 

t 

t 

C.4.8.2. 1 

"0P1  Library  Vol. 

{  1  3  14  2  2  4  17 

m 

m 

in 

X 

X 

X 

1 " : inact  i vi  tyT  imeout 

} 

C.4.8.2. 2 

"0P1  Library  Vol, 

{  1  3  14  2  2  4  26 

m 

m 

m 

X 

X 

X 

1":fT)axPDUSize 

> 

r  A  A  5  X 

x,  ranspor  Lwunnec  L  i  wn  i  vnui  u 

/■IT  1/51/1 
> 

X 

m 

X 

X 

X 

X 

C.4.8.2. 4 

"Rec.  X.721  1  I  SO/ 1  EC 

{29327  50} 

X 

Cl 

X 

X 

X 

X 

10165-2  :  1992": 

al lomorphs 

C.4.8.2. 5 

"Rec.  X,721  i  ISO/ 1  EC 

C  2  9  3  2  7  63  } 

X 

m 

X 

X 

X 

X 

10165-2  :  1992": 

nameBinding 

C.4.8.2. 6 

"Rec.  X.721  j  ISO/IEC 

{  2  9  3  2  7  65  } 

X 

m 

X 

X 

X 

X 

10165-2  :  1992": 

objectClass 

C.4.8.2. 7 

"Rec.  X.721  1  ISO/IEC 

{29327  66) 

X 

c2 

X 

X 

X 

X 

10165-2  :  1992": 

packages 

cl  =  m  if  an  object  supports  al lormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else 
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Table  C.4.8.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Sup 
t 

c 

0 

n 
f 

por 
n 

0 

n 

Add 
Info 

ih- 

Index 

Field  Name 
Label 

ValUc  UT 

OID  of 
Attn  Type 
associatec 
with  Fielc 

us 

Suppo 
rt 

AuQ III una 

I 

Informati 
on 

C.4.8.5. 1 

'  '   ■■"      ■'  ? 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
attributeValueC 
hange 

{  2  9  3  2 
10  1  > 

m 

C.4.8 
.5.1. 
1 

additionallnfo 
rmation 

{  2  9  3  2 
7  6  > 

0 

C.4.8 
.5.1. 

2 

additional  Text 

{  2  9  3  2 
7  7  > 

0 

C.4.8 
.5.1. 
3 

attributeldent 
if ierList 

{  2  9  3  2 
7  8  > 

0 

C.4.8 
.5.1. 

4 

attributeValue 
ChangeDef initi 
on 

{  2  9  3  2 
7  10  > 

m 

C.4.8 
.5.1. 

5 

correlatedNoti 
fi cat  ions 

{  2  9  3  2 
7  12  > 

0 

C.4.8 
.5.1. 

6 

notif icationid 
ent  i  f  i  er 

{  2  9  3  2 
7  16  > 

0 

C.4.8 
.5,1. 
7 

sourcelndicato 
r 

{  2  9  3  2 
7  26  > 

0 

C.4.8.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
objectCreation 

{  2  9  3  2 
10  6  > 

m 

C.4.8 
.5.2. 

1 

additionallnfo 
rmation 

{  2  9  3  2 
7  6  > 

0 

C.4.8 
.5.2. 

2 

additional  Text 

{  2  9  3  2 
7  7  > 

0 

C.4.8 
.5.2. 
3 

attributeList 

{  2  9  3  2 
7  9  > 

0 

C.4.8 

.5.2. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2 
7  12  > 

0 

C.4.8 
.5.2. 
5 

notif icationid 
entif ier 

{  2  9  3  2 
7  16  > 

0 

C.4.8 
.5.2. 

6 

sourcelndicato 
r 

{  2  9  3  2 
7  26  > 

0 

C.4.8.5. 3 

"Rec.  X.721  1 
ISO/IEC  10165-2 
:  1992": 
objectDeletion 

{  2  9  3  2 
10  7  } 

m 

C.4.8 
.5.3. 
1 

additionallnfo 
rmation 

{  2  9  3  2 
7  6  > 

0 

C.4.8 
.5.3. 

2 

addi  tionalText 

{  2  9  3  2 
7  7  > 

0 

C.4.8 
.5.3. 

3 

attributeList 

{  2  9  3  2 
7  9  > 

0 

C.4.8 
.5.3. 

4 

correlatedNoti 
fi cat  ions 

{  2  9  3  2 
7  12  > 

0 

C.4.8 
.5.3. 

5 

notif icationid 
ent i  f ier 

{  2  9  3  2 
7  16  } 

0 
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Index 

Not  i  f  i  cat  i  on 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

SuF>por 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
010  of 
Attr  Type 
associated 
with  Field 

Stat 
us 

Suppo 
rt 

Addi  tiona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.8 
.5.3. 
6 

sourcelndicato 
r 

{  2  9  3  2 
7  26  > 

0 

C.4.9    Transport  Connection  Retransmission  IVIVIO  MOCS  Proforma 


Managed  Object  class  template  label 

Value  of  Object  identifier  for  class 

"0P1  Library  Vol. 

2" : t ranspor tConnect  i  onRet  ransmi  ss  i  onl VMO 

{  1  3  14  2  1  1  3  > 

Are  all  mandatory  features  of  the  class  supported?  Yes   No 


Table  C.4.9.1  -  Name  Binding  Support 


Index 

Name  Binding  Template  Label 

Value  of  Object 
Identifier  for 
Name  Binding 

Superior  Object 
Class  Template 
Label 

Stat 
lis 

Suppo 
rt 

Status 

Suppor 
t 

Addition 
al 

Informat 
ion 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

c 
r 
e 
a 
t 
e 

d 
e 
I 
e 
t 
e 

C.4.9. 1.1 

transportConnectionlVMO- 

coTransportProtocolLayerEnt 

ity 

{  1  3  14  2  1  3  1 
> 

"0P1  Library  Vol. 
1": 

coTransportProtoco 
ILayerEntity 

0 

X 

X 

C.4.9. 1.2 

t  ranspor tConnect  i  onRet  ransm 
issionlVMO- 

coT ranspor tProtocolLayerEnt 
ity 

{  1  3  14  2  1  3  2 
> 

"0P1  Library  Vol. 
1": 

coTransportProtoco 
ILayerEntity 

0 

X 

X 
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Table  C.4.9.2  -  Attribute  Support 


Index 

Attribute  Template  Label 

Value  of  Object 
Identifier  for 
Attribute 

Status 

Support 

Additional 
Information 

s 
e 
t 
b 

y 

c 
r 

3 

t 

e 

g 

e 
t 

r 

e 

P 
I 
a 
c 
e 

a 
d 
d 

r 
e 

m 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

s 
e 
t 
b 

y 

c 
r 
e 
a 
t 
e 

g 
e 
t 

r 
e 
P 
I 
a 
c 
e 

a 
d 
d 

r 

e 

fn 

0 
V 

e 

s 
e 
t 
t 

0 

d 
e 
f 
a 
u 
I 
t 

C.4.9.2. 1 

"0P1  Library  Vol. 

1 " : maxRet  ransmi  ss  i  ons 

C  1  3  14  2  2  4  27 
> 

m 

m 

m 

X 

X 

X 

C.4.9.2. 2 

"0P1  Library  Vol.  1": 

ret  ransmi  ss  i  onT  i  mer I ni  t  i  a I 

Value 

{  1  3  14  2  2  4  49 
> 

m 

m 

m 

X 

X 

X 

C.4.9.2. 3 

"0P1  Library  Vol. 
1 " : i  nac t  i  v  i  tyT  i  meout 

{  1  3  14  2  2  4  17 
> 

fn 

ID 

m 

X 

X 

X 

C.4.9.2. 4 

"0P1  Library  Vol. 
1":niaxPDUSize 

{  1  3  14  2  2  4  26 
> 

m 

m 

tn 

X 

X 

X 

C.4.9.2. 5 

transportConnectionlVMOId 

{  1  3  14  2  1  4  1 
> 

x 

m 

X 

X 

X 

X 

C.4.9.2. 6 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
al  lotnorphs 

{29327  50  > 

X 

Cl 

X 

X 

X 

X 

C.4.9.2. 7 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
nameBinding 

C29327  63  > 

X 

m 

X 

X 

X 

X 

C.4.9.2. 8 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
objectClass 

{  2  9  3  2  7  65  > 

X 

m 

X 

X 

X 

X 

C.4.9.2. 9 

"Rec.  X.721  1  ISO/IEC 
10165-2  :  1992": 
packages 

C2932766> 

X 

c2 

X 

X 

X 

X 

cl  =  m  if  an  object  supports  allormorphism,  else  - 

c2  =  m  if  any  any  registered  package  (other  than  this  package)  has  been  instantiated,  else 
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Table  C.4.9.5  -  Notification  Support 


Index 

Notification 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 
us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
OID  of  Attr 
Type 

associated 

NiLii  riciu 

Stat 
us 

Suppo 
rt 

Additiona 
I 

Inf ormati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.9.5. 1 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
attributeValue 
Change 

{  2  9  3  2 
10  1  > 

ID 

C.4.9 
.5.1. 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.9 
.5.1. 

2 

addi  tionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.9 
.5.1. 

3 

attributeldent 
if ierList 

{  2  9  3  2  7 
8  > 

0 

C.4.9 
.5.1. 

4 

attributeValue 
ChangeDef initi 
on 

{  2  9  3  2  7 
10  > 

fn 

C.4.9 
.5.1. 
5 

correlatedNoti 
f  i  cat  i  ons 

{  2  9  3  2  7 
12  > 

0 

C.4.9 
.5.1. 

6 

notif icat ion Id 
entif ier 

{  2  9  3  2  7 
16  } 

0 

C.4.9 
.5.1. 

7 

sourcelndicato 
r 

{  2  9  3  2  7 
26  } 

0 

C.4.9.5. 2 

"Rec.  X.721  1 
ISO/IEC  10165- 
2  :  1992": 
objectCreation 

C  2  9  3  2 
10  6  > 

m 

C.4.9 
.5.2. 

1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  > 

0 

C.4.9 
.5.2. 

2 

additionalText 

{  2  9  3  2  7 
7  } 

0 

C.4.9 
.5.2. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.9 
.5.2. 

4 

correlatedNoti 
f icat ions 

{  2  9  3  2  7 
12  > 

0 

C.4.9 
.5.2. 

5 

notif icat ionid 
entif ier 

{  2  9  3  2  7 
16  > 

0 

C.4.9 
.5.2. 

6 

sourcelndicato 
r 

{  2  9  3  2  7 
26  } 

0 

C.4.9.5. 3 

"Rec.  X.721  j 
ISO/IEC  10165- 
2  :  1992": 
objectDeletion 

{  2  9  3  2 
10  7  > 

m 

C.4.9 
.5.3. 
1 

additional  Info 
rmation 

{  2  9  3  2  7 
6  } 

0 

C.4.9 
.5.3. 

2 

additionalText 

{  2  9  3  2  7 
7  > 

0 

C.4.9 
.5.3. 

3 

attributeList 

{  2  9  3  2  7 
9  > 

0 

C.4.9 
.5.3. 

4 

correlatedNoti 
f icat ions 

{  2  9  3  2  7 
12  } 

0 

C.4.9 
.5.3. 

5 

notif icat ionId 
entif ier 

{  2  9  3  2  7 
16  > 

0 
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Index 

Motif ication 
Type  Label 

Value  of 
Notif icatio 
n  Type 
Identifier 

Stat 

us 

Suppor 
t 

Add 
Info 

Sub- 
Index 

Notification 
Field  Name 
Label 

Value  of 
DID  of  Attr 
Type 

associated 
with  Field 

Stat 

LIS 

Suppo 
rt 

Additiona 
I 

Informati 
on 

c 

0 

n 
f 

n 

0 

n 

C.4.9 
.5.3. 
6 

source! ndicato 
r 

{29327 
26  > 

0 
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Part  19  -  Remote  Database  Access 


December  1992  (Stable) 


Foreword 


This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Remote  Dataisase  Access  Special 
Interest  Group  (RDA  SIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW).  See  Procedure 
Manual  for  Workshop  Charter. 

Text  In  this  part  has  been  approved  by  the  Plenary  of  the  Workshop.  This  part  replaces  the  previously 
existing  part  on  this  subject. 

Future  changes  and  additions  to  this  version  of  these  Implementation  Agreements  will  be  published  as 
change  pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be 
shown  as  shaded. 

The  text  In  this  part  contains  a  set  of  Remote  Database  Access  (RDA)  Implementation  Agreements  intended 
to  serve  In  lieu  of  an  International  Standardized  Profile  (ISP)  for  RDA.  It  is  the  aim  of  the  OIW  RDA  SIG  to 
pursue  alignment  of  this  part  with  a  future  RDA  ISP.  When  the  ISP  is  complete,  this  part  will  be  revised  to 
refer  to  the  ISP,  and  to  only  highlight  additional  practices  and  North  American  regional  requirements. 
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Part  19  -  Remote  Database  Access 

0  Introduction 

This  part  defines  Impiementatlon  Agreements  based  on  ISO  Remote  Datat)ase  Access,  as  defined  in  iSO/ 
lEC  9579.  That  specification  has  two  parts.  Part  1  defines  the  RDA  Generic  Model,  Service,  and  Protocol; 
part  2  defines  the  RDA  SQL  Specialization. 

1  Scope 

This  Implementation  agreement  addresses  interaction  t)etween  an  application  program  and  a  remote 
database  server.  The  database  server  is  an  open  system  that  provides  database  storage  facilities  and 
supplies  database  processing  services  to  clients  at  other  open  systems. 

The  RDA  service-provider  supplies  the  protocol  for  RDA  client  interaction  with  an  RDA  server.  The  RDA 
client  initiates  an  RDA  dialogue  and  requests  RDA  operations  to  t>e  performed  by  the  RDA  server  on  behalf 
of  an  application  program.  The  RDA  server,  located  within  the  RDA  database  server,  provides  database 
services  to  RDA  clients. 

More  specifically,  this  document  describes  implementation  agreements  in  the  following  areas: 

a)  limitations  on  values  of  parameters  of  the  RDA  protocol; 

b)  other  restrictions  on  operations  of  an  RDA  client  or  server; 

c)  profiles. 

These  agreements  presently  include  only  the  RDA  SQL  Specialization  Basic  Application  Context. 

2  Status 

The  following  clauses  were  moved  to  the  Stable  Implementation  Agreements  in  December  1992  : 
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Annex  A  (normative),  RDA  SIG  object  identifiers 


3    Normative  references 

The  following  documents  contain  provisions  wtiicii,  througii  reference  in  ttiis  text,  constitute  provisions  of 
these  Implementation  Agreements.  At  the  time  of  publication,  the  editions  indicated  were  valid.  Ail 
documents  are  subject  to  revision,  and  parties  to  agreements  based  on  these  Implementation  Agreements 
are  warned  against  automatically  applying  any  more  recent  editions  of  the  documents  listed  t>elow  since  the 
nature  of  references  made  by  the  Implementation  Agreements  to  such  documents  is  that  they  may  be 
specific  to  a  particular  edition.  Members  of  lEC  and  ISO  maintain  registers  of  currently  valid  International 
Standards,  and  CCITT  maintains  published  editions  of  its  current  recommendations. 

[1]       ISO/IEC  9579-1  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Remote 
Datat3ase  Acce^  •  Part  1:  Generic  Model.  Service,  and  Protocol. 

[2]      ISO/IEC  9579-2  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Remote 
DaUit)ase  Access  -  Part  2:  SQL  Specialization. 

[3]       ISO/IEC  TR1 0000-1 :  1990(E)  Information  Technology  -  Framework  and  Taxonomy  of  International 
Standaidlzed  Profiles  -  Part  1:  Framework. 

[4]       ISO/IEC  TR1 0000-2: 1990(E)  Information  Technology  -  Framework  and  Taxonomy  of  International 
Standardized  Profiles  -  Part  2:  Taxonomy. 

[5]       ISO/IEC  8859-1 :1987  Information  Processing  -  8-bit  single-byte  coded  graphic  characters  sets  - 
Part  1:  Latin  alphabet  No.  1. 


4    Definitions  and  abbreviations 

Definitions  and  abbreviations  are  given  In  the  standards  listed  in  clause  3. 


5    Structure  of  RDA  standards 

The  complete  specification  of  an  RDA  Service  is  only  obtained  by  the  combination  of  two  standards: 

a)  the  RDA  Generic  Model,  Service,  and  Protocol  (ISO/IEC  9579-1),  which  specifies  general 
capabilities  of  any  RDA  service;  and 

b)  an  RDA  Specialization,  which  applies  to  a  particular  type  of  database  language  and  augments 
the  RDA  Generic  standard. 

Since  RDA  Specializations  "complete"  an  RDA  specification,  these  Implementation  Agreements  are  based 
on  RDA  Specializations  rather  than  on  the  RDA  Generic  standard. 

At  present  there  is  only  one  RDA  Specialization,  the  RDA  SQL  Specialization  (ISO/IEC  9579-2). 
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6    SQL  specialization 


6.1      Service  parameter  limits/agreements 

This  subclause  states  the  limits  on  the  values  of  RDA  parameters  for  the  RDA  Basic  Application  Context. 

NOTE  -  Limits  for  the  RDA  TP  Application  Context  will  be  defined  at  a  later  time. 

A  tabular  fornnat  is  used  to  describe  the  usage  of  each  RDA  parameter  and  its  limit.  Limits  vary  among 
implementations.  This  subclause  defines  the  range  of  parameter  values  that  developers  may  safely  assume 
all  OlW-compiiant  systems  support. 

Each  parameter  table  indicates  the  following: 

a)  the  name  of  the  parameter; 

b)  whether  it  is  sent  in  the  request  or  response  service  primitive  under  these  Implementation 
Agreements; 

c)  whether  it  is  received  in  the  indication  or  confirm  service  primitive  under  these  Implementation 
I  Agreements; 

!  d)  the  limitations  on  the  parameter. 

The  Parameter  column  gives  the  name  of  the  parameter  or  type,  as  defined  in  either  the  service  parameter 
tables  or  the  ASN.1  for  the  protocol  data  units  of  ISO/I  EC  9579-1  and  9579-2. 

NOTE  -  Parameter  names  begin  with  a  lowercase  letter,  and  type  names  begin  with  an  uppercase  letter. 

The  req  (ind)  column  states  whether  the  parameter  is  present  in  the  request  (indication)  service  primitive 
I  event. 

The  rsp  (cnf)  column  states  whether  the  parameter  is  present  in  the  response  (confirm)  service  primitive 
event. 

The  Limitation  column  gives  the  limits  on  the  parameter  value  in  addition  to  any  limits  imposed  by  the 
!  RDA  standard.  The  maximum  value  indicated  for  the  limit  imposed  by  these  Implementation  Agreements 

is  a  min-max  limit.  This  means  that  an  OlW-compliant  implementation  must  support  minimally  at  least  the 

min-max  value.  An  implementation  can  support  values  beyond  the  min-max  value  but  it  can  not  expect  other 
]  implementations  to  do  the  same.  Hence,  an  implementation  should  stay  within  the  min-max  limit  when  it 

is  interoperating  with  another  implementation. 

I  If  a  parameter  value  is  outside  the  range  specified  in  the  Limitation  column  for  that  parameter,  then  the 
behavior  is  outside  the  scope  of  these  Implementation  Agreements. 

Each  RDA  parameter  is  listed  on  a  separate  line.  Some  parameters  are  structures,  composed  of 
subparameters.  The  structure  is  shown  by  the  bullet  (•)  symbols  in  the  parameter  column.  A  parameter 
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name  preceded  by  bullets  is  a  subparameter  of  the  nearest  entry  above  it  tliat  lias  one  fewer  bullet.  In  the 
example  below,  parameterA  and  parameterB  are  subparameters  of  the  structure  parameter  parameterX,  and 
parameterC  is  a  subparameter  of  parameterB  : 

parameterX 


•parameterA 


•parameterB 
•parameterC 


The  presence  of  subparameters  is  always  dependent  on  the  presence  of  the  parameter  that  they  appear 
under  (for  example,  an  optional  parameter  may  have  subparameters;  if  the  parameter  is  not  supplied,  then 
no  subparameters  may  be  supplied). 

Under  each  req,  IfKi,  rsp,  or  cnf  column,  a  code  is  used  to  specify  the  type  of  usage  of  each  RDA  parameter. 
For  the  sake  of  explanation,  let  x  represent  the  entry  under  columns  req,  rsp,  ind,  and  cnf. 

If  X  is  M.  the  parameter  is  mandatory. 

If  X  is  U,  the  parameter  is  a  user  option  and  may  or  may  not  be  provided,  depending  upon  the  requirements 
of  the  user. 

if  X  is  C,  the  parameter  is  conditional  and  subject  to  rules  stated  In  the  parameter  description  in  ISO/IEC 
9579-1  and  9579-2. 

if  X  is  S,  the  parameter  is  a  mandatory  selection  from  a  collection  of  two  or  more  possible  parameters.  The 
parameters  that  make  up  this  collection  are  indicated  in  the  parameter  table  as  follows: 

a)  each  parameter  in  the  collection  is  specified  with  the  code  "S"; 

b)  the  name  of  each  parameter  in  the  collection  has  the  same  number  of  bullets  preceding  it  in  the 
parameter  column  in  the  table;  and 

c)  either 

1)  each  parameter  has  no  bullets  preceding  it  in  the  tat>le;  or 

2)  each  parameter  is  part  of  the  same  structure  parameter. 


If  X  is  I,  the  parameter  is  out  of  the  scope  of  this  profile.  The  parameter  is  optional  in  the  base  standard  but 
is  not  used  by  this  profile,  or  the  parameter  is  not  used  by  the  RDA  SQL  specialization.  The  parameter  may 

be  present.  If  present,  it  is  ignored  or  processed  according  to  local  procedures;  it  does  not  cause  an  error. 

A  blank  code  indicates  the  parameter  is  never  present. 

If  X  includes  (=),  the  parameter  is  semantically  equivalent  to  the  parameter  in  the  service  primitive  to  its  left 


/ 
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6.1.1.1.1  R-lnitialize  request 


Table  1  -  Parameters  for  R-lnitialize  request 


Parameter 

req 

ind 

Limitation 

operation!  D 

M 

) 

An  INTEGER  with  value  greater  than 
0. 

dialoguelD 

M 

M(= 

) 

See  subparameter(s)  below. 

•dialoguelDCIient- 
Invocation 

M 

See  subparameter(s)  below. 

••aP-tltle 

M 

M(= 

) 

No  additional  limitation. 

••aE-qualifier 

M 

M(= 
) 

No  additional  limitation. 

••aP-invocationID 

M 

M(  = 
) 

No  additional  limitation. 

••aE-invovationID 

M 

M(  = 

) 

No  additional  limitation. 

•dialoguelDSuffix 

M 

M(= 
) 

An  OCTET  STRING  from  1  through  64 
octets  long. 

identityOfUser 

M 

M(= 
) 

A  VisibleString  from  1  through  64 
characters  long. 

userAuthenticationData 

1 

l(=) 

The  client  may  provide  an  lASString 
from  1  through  255  characters  long, 
an  OCTET  STRING  from  1  through 
255  octets  long,  or  a  BIT  STRING 
from  1  through  2040  bits  long. 

controlSery/iceData- 
Requested 

(default  value:  FALSE) 

M 

M(= 
) 

No  additional  limitation. 

functlonalUnltsRequested 

M 

M(= 
) 

No  additional  limitation. 

sQUnltializeArgument 

U 

C(= 
) 

See  subparameter(s)  below. 

•sQLConformanceLevel- 
Default 

U 

C(= 
) 

An  OBJECT  IDENTIFIER  from  2 
through  16  elements. 

•userData 

1 

l(=) 

An  OCTET  STRING  from  1  through 
255  octets  long. 
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6.1.1.1.2  R-lnitialize  result 


Table  2  -  Parameters  for  R-lnitialize  result  response 


Parameter 

rsp 

cnf 

Limitation 

operatlonID 

M 

M(= 

An  INTEGER  with  value  greater  than 
0. 

controlSen/lceData 

C 

C(= 
) 

See  subparameter(s)  below. 

•controlServicesAilowecl 
(default  value:  TRUE) 

M 

M(= 
) 

No  additional  limitation. 

•controlAuthentication- 
Data 

1 

l(=) 

The  server  may  provide  an  lASString 
from  1  through  255  characters  long, 
an  OCTET  STRING  from  1  through 
255  octets  long,  or  a  BIT  STRING 
from  1  through  2040  bits  long. 

functlonalUnitsAllowed 

M 

M(= 
) 

No  additional  limitation. 

sQUnitializeResult 

U 

C(= 
) 

See  subparameter(s)  below. 

•userData 

K=) 

An  OCTET  STRING  from  1  through 
255  octets  long. 

6.1.1.1.3  R-lnitialize  error 

Table  3  -  Parameters  for  R-lnitialize  error  response 


Parameter 

rsp 

cnf 

Limitation 

operatlonID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

accessControlViolation 

S 

S(= 
) 

No  additional  limitation. 

duplicateDialoguelD 

S 

S(= 

) 

No  additional  limitation. 

invalidSequence 

s 

See  subparameter(s)  below. 

•diagnostici  nf  ornmation 

u 

No  additional  limitation. 
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Parameter 

rsp 

cnf 

Limitation 

operationAborted 

S 

S(= 
) 

See  subparameter(s)  below.  | 

•errorType  (default 
valueitransient) 

M 

M(= 
) 

No  additional  limitation.  1 

•dlagnosticlnformation 

U 

C(= 
) 

A  VlslWeString,  from  1  through  254 
characters  long. 

userAuthentlcationFailure 

S 

S(= 
) 

No  additional  limitation. 

6.1.1.2        R-Synchronize  APDU 

The  R-Synchronize-RI  APDU  has  no  parameters. 

6.1.2       Dialogue  termination  functional  unit 
6.1.2.1        R-Termlnate  service 

I 

I  6.1.2.1.1  R-Terminate  request 

j   Table  4  -  Parameters  for  R-Terminate  request 


Parameter 

req 

ind 

Limitation 

operationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

6.1.2.1.2          R-Terminate  result 

Table  5  -  Parameters  for  R-Terminate  result  response 

Parameter 

rsp 

cnf 

Umltatlon 

operationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 
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Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

duplicateOperationlD 

S 

S(=) 

No  additional  limitation. 

invalidSequence 

S 

See  subparameter(s)  be\ow. 

•diagnostidnfbmnation 

u 

No  additional  limitation. 

operationAborted 

S 

S(=) 

See  8ubparameter(s)  be\o\N. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additlonai  limitation. 

•diagnostic!  nformation 

U 

C(  = 
) 

A  VisiisleString  from  1  through  254 
characters  long. 

serviceNotNegotiated 

S 

S(= 

) 

No  additional  limitation. 

6.1.3       Transaction  management  functional  unit 
6.1.3.1        R-Beginlransaction  service 

6.1.3.1.1  R-BeginTransaction  request 

Table  7  -  Parameters  for  R-BeginTransactlon  request 


Parameter 

req 

ind 

Limitation 

OperationID 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

10 
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6.1.3.1.2  R-BeginTransaction  error 

  Table  8  -  Parameters  for  R-BeginTransaction  error  response 


Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

i^(= 
) 

An  INTEGER  with  value  greater  than 
0. 

dupllcateOperationID 

S 

S(= 
) 

No  additional  limitation. 

invalldSequence 

s 

See  subparameter(s)  below. 

•diagnostlclnformation 

u 

No  additional  limitation. 

operationAborted 

S 

S(= 

) 

See  subparameter(s)  below. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnostlclnforniatlon 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

servlceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 

6.1.3.2        R-Commit  service 


6.1.3.2.1  R-Commit  request 

  Table  9  -  Parameters  for  R-Commit  request 


Parameter 

req 

Ind 

Limitation 

operationID 

M 

) 

An  INTEGER  with  value  greater  than 

0. 

6.1.3.2.2          R-Commit  result 

Table  10  -  Parameters  for  R-Commit  result  response 

Parameter 

rsp 

cnf 

Limitation 

OperationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

transactionResutt 

M 

M(=) 

No  additional  limitation. 
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6.1.3.2.3  R-Commit  error 

Table  1 1  -  Parameters  for  R-Commit  error  response 


Parameter 

rsp 

cnf 

Limitation 

operationlD 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

duplicateOperationlD 

S 

S(=) 

No  additional  limitation. 

invalidSequence 

S 

See  subparameter(s)  below. 

•diagnostici  nfbrmation 

u 

No  additional  limitation. 

6.1.3.3        R-Rollback  service 

6.1.3.3.1  R-Rollback  request 

Table  12  -  Parameters  for  R-Rollback  request 


Parameter 

req 

ind 

Limitation 

operationlD 

M 

) 

An  INTEGER  with  value  greater  than 
0. 

6.1.3.3.2           R-Rollback  result 

Table  13  -  Parameters  for  R-Rollback  result  response 

Parameter 

rsp 

cnf 

Limitation 

OperationlD 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

6.1.3.3.3  R-Rollback  error 
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ParanfMtar 

rap 

cnf 

Limitation 

operationlD 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

duplicateOperationID 

S 

S(=) 

No  additional  limitation. 

invalidSequence 

S 

See  subparameter(s)  below. 

•diagnostidnfbrmation 

u 

No  additional  limitation. 

6.1.4       Cancel  functional  unit 

6.1.4.1        R-Cancel  service 

6.1.4.1.1  R-Cancel  request 

Table  15  -  Parameters  for  R-Cancel  request 


Parameter 

req 

Ind 

Limitation 

operationlD 

M 

M(= 

An  INTEGER  with  value  greater  than 
0. 

controlledDialogue 

U 

C(= 

See  subparameter(s)  below. 

•dialoguelD 

M 

M(= 

See  subparameter(s)  below. 

••dialogue!  DCIient- 
Invocation 

U 

C(= 

See  subparameter(s)  below. 

•••aP-title 

M 

M(= 

No  additional  limitation. 

•••aE-qualifier 

M 

M(= 

No  additional  limitation. 

•••aP-invocationiD 

M 

M(= 

No  additional  limitation. 

•••aE-invocationlD 

M 

M(= 

No  additional  limitation. 

•  •dialogue!  DSuffIx 

M 

An  OCTET  STRING  from  1  through  64 
octets  long. 

13 
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1  Parameter 

req 

ind 

Limitation 

•contrdAuthenticationData 

M 

M(= 
) 

The  client  may  provide  an  lASString 
from  1  tlirougli  255  cliaracters  long, 
an  OCTET  STRING  from  1  through 
255  octets  long,  or  a  BIT  STRING 
from  1  to  2040  bits  long. 

listOfOperationID 

U 

C(= 
) 

This  list  nnay  contain  from  1  through 
32  entries  of  OperationiD. 

•OperationiD 

C 

C(= 
) 

An  INTEGER  with  value  greater  than 
0. 

6.1.4.1.2  R-Cancel  result 

Table  16  -  Parameters  for  R-Cancel  result  response 


Parameter 

rsp 

cnf 

LimKation  [ 

OperationiD 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

6.1.4.1.3          R-Cancel  error 

Table  17  -  Parameters  for  R-Cancel  error  response 

Parameter 

rsp 

cnf 

Limitation 

OperationiD 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

controlAuthenicationFailure 

S 

S(=) 

No  additional  limitation. 

controlServices- 
NotAllowed 

S 

S(= 
) 

No  additional  limitation. 

dialoguelDUnknown 

S 

S(= 
) 

No  additional  limitation. 

duplicateOperationID 

S 

S(= 

) 

No  additional  limitation. 

invalidSequence 

s 

See  subparameter(s)  below. 

•diagnosticlnformation 

u 

No  additional  limitation. 

operationAborted 

8 

S(= 

) 

See  subparameter(s)  below. 
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Parameter 

rsp 

cnf 

Limitation 

1  •errorType  (default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation.  1 

•diagnostici  nformation 

U 

C(= 
) 

A  Visit)leString,  from  1  through  254 
characters  long. 

sen/iceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 

6.1.5       Status  functional  unit 


6.1.5.1        R-Status  seivice 


6.1.5.1.1  R-Statu8  request 

Table  18  -  Parameters  for  R-Status  request 


Parameter 

req 

ind 

Limitation 

operationID 

M 

M(= 

An  INTEGER  with  value  greater  than 
0. 

controlledDlalogue 

U 

C(= 

See  subparameters  below. 

•dialoguelD 

M 

M(= 

See  subparameter(s)  l^elow. 

••dialoguelDOient- 
Invocation 

U 

C(= 

See  subparameter(s)  below. 

•••aP-title 

M 

M(= 

No  additional  limitation. 

•••aE-qualifier 

M 

M(= 

No  additional  limitation. 

•••aP-invocationID 

M 

M(= 

No  additional  limitation. 

•••aE-invocationID 

M 

M(= 

No  additional  limitation. 

••dialoguelDSuffIx 

M 

M(= 

An  OCTET  STRING  from  1  through  64 
octets  long. 

15 
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1  Parameter 

req 

ind 

Limitation 

•controiAuthentlcationData 

M 

M(= 
) 

The  client  may  provide  an  lASString 
from  1  tiirough  255  characters  long, 
an  OCTET  STRING  from  1  through 
255  octets  long,  or  a  BIT  STRING 
from  1  to  2040  bits  long. 

listOfOperationID 

U 

C(= 
) 

This  list  may  contain  from  1  through 
32  entries  of  OperationID. 

1  •OperationID 

C 

C(= 
) 

An  INTEGER  with  value  greater  than 
0. 

6. 1 .5. 1 .2  R-Status  result 

Table  19  -  Parameters  for  R-Status  result  response 


1  Parameter 

rsp 

cnf 

Limitation 

1  OperationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

listOfStatuslnformation 

C 

C(=) 

This  list  may  contain  from  1  through  32 
entries  of  Statuslnformation. 

•Statuslnformation 

U 

C(=) 

See  subparameter(s)  t)elow. 

••OperationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

••operationStatus 

M 

M(=) 

See  choice(s)  below. 

•••operationlDUnknown 

8 

8(=) 

No  additional  limitation. 

•  •  •awaitingExecution 

S 

8(=) 

No  additional  limitation. 

•••executing 

S 

8(=) 

No  additional  limitation. 

•••finished 

8 

8(=) 

No  additional  limitation. 

•••cancelled 

8 

S(=) 

No  additional  limitation. 

•••alxdrted 

S 

8(=) 

A  VisibleString  with  value  from  1  through 
254  characters  long. 

6. 1 .5. 1 .3  R-Statu8  error 
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Table  20  -  Parametef  for  R-Status  error  response 


Parameter 

rsp 

cnf 

1 

Umitation  | 

operationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

oontrdAuthenticationFailure 

S 

S(=) 

No  additional  limitation. 

oontroiServioes- 
NotAllowed 

S 

S(= 

) 

No  additional  limitation. 

dialoguelOUnknown 

S 

S(= 

) 

No  additional  limitation. 

duplicateOperationID 

S 

S(= 

) 

No  additional  limitation. 

1  invaiidSequence 

s 

See  subparameter(s)  below. 

1  •diagnosticlnformation 

u 

No  additional  limitation. 

operationAborted 

S 

S(= 

) 

See  subparameter(s)  below. 

•errorType 

(default  value:  transient) 

M 

M(= 
) 

No  additional  limitation. 

•dlagnostlclnfomfiation 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

servlceNotNegotlated 

S 

S(= 
) 

No  additional  limitation. 

6.1.6       Resource  handling  functional  unit 


6.1.6.1  R-Open  service 
6.1.6.1.1  R-Open  request 


Part  19  •  Remote  Database  Access  December  1992  (Stable) 


Table  21  -  Parameters  for  R-Open  request 


1  ParanfMter 

req 

ind 

Limitation 

1  operationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

dataResourceHandle 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

parentDataResourceHandle 

1 

l(  =  ) 

An  INTEGER  with  value  geater  than  0. 

A  ViftihlARtrinn  from  1  thrni  inh  O^A 

ry  V  lOIUIOwll  II         livJill    1   llllwU^li  ^yj*r 

characters  long. 

sQLAccessControlData 

1 

l(=) 

The  dient  may  provide  an  lASString  from 
1  through  255  characters  long,  an 
OCTET  STRING  from  1  through  255 
octets  long,  or  a  BIT  STRING  from  1 
through  2040  bits  long. 

1  sQLUsageMode 

U 

C(=) 

No  additional  limitation. 

sQLOpenArgument 

U 

C(=) 

See  subparam6ter(s)  below. 

•charSet 

u 

C(=) 

An  OBJECT  IDENTIFIER  from  2  through 
16  elements  long. 

•sQLConformanceLevel 

u 

C(=) 

An  OBJECT  IDENTIFIER  from  2  through 
16  elements  long. 
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6.1.6.1.2  R-Open  result 


Table  22  -  Parameters  for  R-Open  result  response 


Parameter 

rsp 

cnf 

Limitation 

operatlonID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

sQLOpanResult 

U 

C(= 
) 

See  subparameter(s)  below. 

•charSet 

U 

C(= 
) 

An  OBJECT  IDENTIFIER  from  2 
through  16  elements  long. 

•charSetNotSupported 
(default  value :  FALSE) 

U 

C(= 
) 

No  additional  limitation. 

•sQLConformanceLevel 

C 

C(= 
) 

An  OBJECT  IDENTIFIER  from  2 
through  16  elements  long.  | 

6.1.6.1.3  R-Open  error 

  Table  23  -  Parameters  for  R-Open  error  response 


Parameter 

rsp 

cnf 

Limitation 

operatlonID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

dataResourceAlreadyOpen 

S 

S(= 
) 

See  subparameter(s)  below. 

•dataResourceHandle 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

dataResourceNameNot- 
Speclfied 

S 

S(= 
) 

No  additional  limitation. 

dataResourceNotAvailable 

S 

S(= 
) 

See  subparameters  below. 

•errorType  (default  value  : 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnostici  nf ormation 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

dataResourceUnknown 

1 

S 

S(= 
) 

No  additional  limitation. 
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Parameter 

rsp 

cnf 

Limitation 

dupilcateDataResource- 
Handie 

S 

S(= 

) 

No  additional  limitation. 

duplicateOperationI  D 

S 

S(= 

) 

No  additional  limitation. 

invalidSequence 

s 

See  subparameter(s)  below. 

•diagnostlcl  nformation 

1  1 

u 

NO  additional  limitation. 

opetBtlonAborted 

S 

S(= 
) 

See  subparameter(s)  t>elow. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnosticlnformation 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

operationCancelled 

S 

S(= 
) 

No  additional  limitation. 

parentDataResource- 
Unknown 

1 

l(=) 

No  additional  limitation. 

serviceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 

sQLOpenError 

S 

S(= 

See  choice(s)  below. 

•invalidSQLConfomiance- 
Level 

S 

S(= 

) 

No  additional  limitation. 

•sQLAccessControl- 
Vioiation 

S 

S(= 

) 

No  additional  limitation. 

•sQLDatabaseResource- 
AlreadyOpen 

S 

S(= 

) 

No  additional  limitation. 

•rDATransactionOpen 

S 

S(= 

) 

No  additional  limitation. 

6.1.6.2        R-Close  service 


6.1.6.2.1  R-Close  request 
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 Table  24  -  Parameters  for  R-Close  request 


1  Parameter 

req 

ind 

Limitation 

1  operalionlO 

M 

M(  =  ) 

An  INTEGER  with  value  greater  than  0. 

listOfDataResourceHandle 

U 

C(=) 

This  list  shall  contain  one  entry  of 
DataResourceHandle. 

1  •DataResourceHandle 

U 

C(=) 

An  INTEGER  with  value  greater  than  0. 

6.1.6.2.2           R-Close  result 

Table  25  -  Parameters  for  R-Close  result  response 

Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

M(= 

An  INTEGER  with  value  greater  than 
0. 

listOfOoseExceptions 

U 

C(= 

This  list  shall  contain  one  entry  of 
CloseException. 

•CloseException 

M 

M(= 

See  subparameter(s)  below. 

••dataResourceHandle 

M 

M(= 

An  INTEGER  with  value  greater  than 
0. 

••CloseException 

M 

M(= 

See  choice(s)  below. 

•••dataResourceHandle- 
Unknown 

S 

S(= 

No  additional  limitation. 

6.1.6.2.3           R-Close  error 

Table  26  -  Parameters  for  R-Close  en-or  response 

Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

dupllcateOperationl  D 

S 

S(= 
) 

No  additional  limitation. 

invalidSequence 

S 

See  subparameter(s)  below. 

•diagnostic!  nformatlon 

U 

No  additional  limitation. 
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operationAborted 

S 

S(= 
\ 

See  subparameter(s)  below. 

•errorType(default 

vcuuo.  Li ai  idici  11/ 

M 

M(= 

\ 
/ 

No  additional  limitation. 

•diagnostici  nformation 

U 

C(= 
) 

A  VisiWeString,  from  1  through  254 
characters  long. 

operationCancelled 

S 

S(= 

) 

No  additional  limitation.  1 

serviceNotNegotiated 

S 

S(= 

) 

No  additional  limitatbn. 

sQLCioseError 

S 

S(= 

) 

See  choice(s)  below. 

•rDATransactionOpen 

S 

S(= 

) 

No  additional  limitation. 

6.1.7       Immediate  execution  DBL  functional  unit 


6.1.7.1         R-ExecuteDBL  service 


6.1.7.1.1  R-ExecuteDBL  request 


22 


Part  19  -  Remote  Database  Access  December  1992  (Stable) 


Table  27  -  Parameters  for  R-ExecuteDBL  request 


1  Parameter 

req 

ind 

UmKation 

operationID 

M 

M(=) 

An  INTEGER  with  value  greater  than  0. 

II 

wi  in  1  cucn  wnn  vaiue  greater  man  u. 

sOLDBLStatement 

M 

M(=) 

See  subparanieter(s)  below. 

•statementText 

M 

M(  =  ) 

An  OCTET  STRING,  from  1  through  4000 
octets  long. 

•charSet 

U 

C(=) 

An  OBJECT  IDENTIFIER,  from  2  through 
16  elements  long. 

sQLOBLArgument- 
Spedfication 

U 

C(=) 

This  parameter  may  contain  1  through 
100  entries  of  SQLDataTypeDescriptor. 

Oo6  lalJIo  Oo,  rcueirn9i6rs  Tor 

SQLDataTypeDescriptor. 

sQLDBLResultS  pacification 

U 

C(=) 

This  parameter  may  contain  1  through 

inf^  ArttriAC  rtf  5501  nsrtaTv/rw^r^AQrrintor 

1  WW  9l  III           KJl  W\m^L^CIIm  1  y  L/w^OOwl  lli^lWI  • 

See  table  39,  Parameters  for 
SQLDataTypeDescriptor. 

dBLArguments 

U 

C{=) 

See  choice(s)  below. 

•sinQlsAraumant 

s 

•  •repetitionCount(defautt 
value:  1) 

M 

M(=) 

An  INTEGER  v>«th  value  from  1  through 
64. 

•  •sQLDBLArgumentValues 

C 

C(=) 

This  parameter  may  contain  from  1 
through  100  entries  of  SQLValue.  See 
table  41 ,  Parameters  for  SQLValue. 

•multipleArgument 

S(  = 

) 

S(=) 

See  subparam6ter(s)  below. 

•  •listOfSQLDBLArgument- 
Values 

M 

M(  =  ) 

This  list  may  contain  from  1  through  64 
entries  of  SQLDBLArgumentValues. 

•••SQLDBLArgumentValues 

C 

C(  =  ) 

This  parameter  may  contain  from  1 
through  100  entries  of  SQLValue.  See 
table  41 .  Parameters  for  SQLValue. 
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6. 1 .7. 1 .2  R-ExecuteDBL  result 


Table  28  -  Parameters  for  R-ExecuteDBL  result  response 


1  Parameter 

 s  

no 

cnf 

Limitation 

operatbnID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 

0. 

sQLDBLResuit- 
Specification 

C 

C(= 
) 

This  parameter  niay  contain  1 
through  100  entries  of 
SQLOataTypeDescriptor.  See  table 
39,  Parameters  for 
SQLDataTypeDescriptor. 

listOfResultValues 

U 

C(= 
) 

This  list  may  contain  1  through  64 
entries  of  ResultValues. 

•ResultValues 

M 

M(= 
) 

See  subparameter(s)  below. 

•  •sQLDBLException 

M 

M(= 
) 

See  table  40,  Parameters  for 
SQLDBLException. 

•  •sQLDBLResultValues 

C 

C(= 
) 

This  parameter  may  contain  1 
through  100  entries  of  SQLValue.  See 
table  41 ,  Parameters  for  SQLValue. 

1 
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6. 1 .7. 1 .3  R-ExecuteDBL  error 


Table  29  -  Parameters  for  R-ExecuteDBL  error  response 


Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

badRepetitionCount 

S 

S(= 

) 

No  additional  limitation. 

dataResourceHandle- 
NotSpecified 

S 

S(= 
) 

No  additional  limitation. 

dataResourceHandle- 
Unknown 

S 

S(= 

) 

No  additional  limitation. 

duplicateOperationI  D 

S 

S(= 

) 

No  additional  limitation. 

invalidSequence 

s 

See  subparameter(s)  below. 

•diagnosticlnformation 

u 

No  additional  limitation. 

noDataResourceAvailable 

S 

S(= 

) 

No  additional  limitation. 

operationAborted 

S 

S(= 

) 

See  subparameter(s)  below. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnostic!  nf  ormatlon 

U 

C(= 
) 

A  VisibleString,  from  1  tlirough  254 
characters  long. 

operationCancelled 

S 

S(= 
) 

No  additional  limitation. 

serviceNotNegotiated 

S 

S(= 

) 

No  additional  limitation. 

transactionRoiledBack 

S 

S(= 

) 

No  additional  limitation. 

sQl^ecuteDBLError 

S 

S(= 

) 

See  choice(s)  below. 

•sQLUsageModeViolation 

S 

S(= 

) 

No  additional  limitation. 

•sQLDBLTransaction- 
StatementNotAllowed 

S 

S(= 

) 

No  additional  limitation. 
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ran 

will 

L  ImitatiAn  1 

klllllMiMVII  1 

•sQLOBLArgumentCount- 

Ml^fWkfch 

IVInM  I  IOti#l  1 

s 

S(= 
) 

No  additional  iimitation.  fl 

•sQLDBLArgumentType- 
Mismatch 

s 

S(= 

) 

No  additional  limitation. 

•sQLDBLNoCharSet 

s 

S(= 

) 

No  additional  limitation. 

•hostldentlfierError 

s 

S(= 

) 

No  additional  limitation. 

•rOATransadionNotOpen 

s 

S(= 

) 

No  additional  limitation.  | 

6.1.8  Stored  Execution  DBL  Functional  Unit 
6.1.8.1        R-DeflneDBL  Service 


6. 1 .8. 1 . 1  R-DefineDBL  request 

  Table  30  -  Parameters  for  R-DefineDBL  request 


1  Parameter 

req 

ind 

UmHatlon 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

commandHandle 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 



dataResourceHandle 

U 

C(= 
) 

An  INTEGER  with  value  greater  than 
0. 

sQLDBLStatement 

M 

M(= 
) 

See  subparameter(s)  below. 

•statementText 

M 

M(= 
) 

An  CX^ET  STRING  from  1  through 
4000  octets  long. 

•charSet 

U 

C(= 
) 

An  OBJECT  IDENTIFIER  from  2 
through  16  elements  long. 
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sQLOBLArgument- 
Specification 

U 

C(= 
) 

This  parameter  may  contain  1 
tlirougli  100  entries  of 
SQLDataTypedescriptor.  See  table  39, 
Parameters  for 
SQI_DataTypeDescriptor. 

sQLOBLResult- 
Specification 

U 

C(= 
) 

This  parameter  may  contain  1 
through  100  entries  of 
SQl-DataTypeDescriptor.  See  table 
39,  Parameters  for 
SQLDataTypeDescriptor. 

6. 1 .8. 1 .2           R-Def ineDBL  resuK 

Table  31  -  Parameters  for  R-DefineDBL  result 

Parameter 

res 

cnf 

Limitation 

operationlO 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

sQLDBLResult- 
Specrfication 

C 

C(= 
) 

This  parameter  may  contain  1  through 
100  entries  of 

SQLDataTypeDescriptor.  See  table 
39,  Parameters  for 
SQLDataTypeDescriptor. 

sQLDBLException 

C 

C(= 
) 

See  table  40,  Parameters  for 
SQLDBLException. 

6.1.8.1.3           R-DefineDBL  error 

Table  32  -  Parameters  for  R-DefineDBL  error 

Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

dataResourceHandle- 
NotSpecified 

S 

S(= 
) 

No  additional  limitation. 

dataResourceHandle- 
Unknown 

S 

S(= 
) 

No  additional  limitation. 

duplicateCommandHandle 

S 

S(= 
) 

No  additional  limitation. 
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rsp 


Limitation 


dupiicateOperationID 


S 


S(= 


No  additional  limitation. 


invalidSequenca 


S®©  sybparameter(s)  beiow. 


•diagnostici  ntormation 


U 


No  additional  limitation. 


noDataResourceAvailable 


No  additional  limitation. 


operationAborted 


S(= 


See  sybparameter(s)  beiow. 


•en-orType(defau!t  value: 
transient) 


M 


M(= 


No  additional  limitation. 


•diagnostici  nformatloo 


U 


A  VisibleString,  from  1  through  254 
characters  long. 


operationCancelled 


S(= 


No  additional  limitation. 


servlceNotNegotiated 


S(= 


No  additional  limitation. 


sQLDefineDBLError 


S(= 


See  choice(s)  below. 


»sQLDBLNoCharSet 


No  additional  limitation. 


•sQ!-DBLTransaction- 
StatementNotAllowed 


S(= 


No  additional  limitation. 


•sQLUsageModeViolation 


No  additional  limitation. 


^hostldentifierError 


No  additional  limitation. 


6.1.8.2 


R-lnvokeDBL  Service 


6.1.8.2.1 


R-lnvolceDBL  request 


Table  33  -  Parameters  for  R-involceDBL  request 


req 


ind 


Limitation 
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operationID 

M 

M(= 

) 

An  llsTTEGER  with  value  greater  than 
0. 

commandHandle 

M 

) 

An  INTEGER  with  value  greater  than 
0. 

oee  cnoice(s)  below. 

*sinyi6/\ryunwni 

e 
o 

5(  = 
) 

See  subparameter(s)  below. 

*  'I  GpGinioimourH 
(Default  Value:  1) 

lit 
M 

M(= 

) 

An  I^JTEGER  with  value  from  1 
through  64. 

•  •sQLDBLArgumentValues 

c 

C(= 

/ 

This  parameter  may  contain  1  through 
luu  eniries  ot  oULvaiue.  oee  table 
41,  Parameters  for  SQLValue. 

•multipleArgument 

s 

S(= 

) 

See  subparameter(s)  below. 

••listOfSQLDBLArgument- 
Values 

M 

M(= 

) 

This  list  may  contain  1  through  64 
entries  of  SQLDBLArgumentValues. 

•  •  •SQLDBLArgument- 
Values 

C(= 

This  parameter  may  contain  1  through 
100  entries  of  SQLValue.  See  table 
41,  Parameters  for  SQLValue. 

6.1.8.2.2           R-lnvokeDBL  result 

Table  34  -  Parameters  for  R-lnvokeDBL  result 

Parameter          j  res 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

sQLDBLResult- 
Specificatlon 

C 

C(= 
) 

This  parameter  may  contain  1  through 
100  entries  of 

SQLDataTypedescriptor.  See  table  39, 
Parameters  for 
SQLDataTypeDescriptor. 

listOfResultValues 

M 

M(= 

) 

This  list  may  contain  1  through  64 
entries  of  ResultValues. 

•ResultValues 

M 

M(= 

) 

See  subparameter(s)  below. 
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••sQLOBLException 

M 

M(= 
) 

See  table  40,  Parameters  for 
SQLOBLException. 

•  •sQLDBLResultValues 

C 

C(= 
) 

This  parameter  may  contain  1  through 
100  entries  of  SQLValue.  See  table 
41 ,  Parameters  for  SQLValue. 

6.1.8.2.3           R°lnvokeDBL  error 

Table  35  -  Parameters  for  R-lnvokeDBL  error 

Parameter 

rsp 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

badRepetitionCount 

S 

S(= 
) 

No  additional  limitation. 

commandHandleUnknown 

S 

S(= 
) 

No  additional  limitation. 

duplicateOperationID 

S 

S(= 
) 

No  additional  limitation. 

invalidSequence 

s 

See  subparameter(s)  below. 

•diagnostici  nformation 

u 

No  additional  limitation. 

operationAborted 

S 

S(= 

) 

See  subparameter(s)  below. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnosticlnformation 

U 

C(= 
) 

A  VisibleString,  from  1  through  254 
characters  long. 

operationCancelled 

S 

S(= 
) 

No  additional  limitation. 

serviceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 

transactionRdledBack 

S 

S(= 

) 

No  additional  limitation. 

sQUnvokeDBLError 

S 

S(= 

) 

See  choice(s)  below. 
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Ptmmoter 

rsp 

cnf 

Limitation  | 

•sQLUsageModeViolation 

S 

S(= 
) 

No  additional  limitation.  1 

•sQLOBLArgumentType- 
Mismatch 

S 

S(= 

) 

No  additional  limitation.  | 

•sQLDBLArgumentCount- 
Mismatch 

s 

S(= 

) 

No  additional  limitation. 

•rOATransactionNotOpen 

s 

S(= 

) 

No  additional  limitation. 

6.1.8.3  R-DropDBL  Service 
6. 1 .8.3. 1  R-DropDBL  request 


Table  36  -  Parameters  for  R-DropDBL  request 


Parameter 

req 

Ind 

Limitation 

operationID 

M 

) 

An  INTEGER  with  value  greater  than 
0. 

listOfCommandHandle 

U 

C(= 
) 

This  list  may  contain  from  1  through 
32  entries  of  CommandHandle. 

•CommandHandle 

C 

C(= 
) 

An  ItJTEGER  with  value  greater  than 
0. 

6.1.8.3.2  R-DropDBL  result 


Table  37  -  Parameters  for  R-DropDBL  result 


Parameter 

res 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

listOfDropDBLExceptlons 

U 

C(= 
) 

This  list  may  contain  1  through  32 
entries  of  DropOBLExceptlon. 

•DropOBLExceptlon 

M 

M(= 
) 

See  subparameter(s)  t)elow. 

1 

31 


Part  19  -  Remote  Database  Access  December  1992  (Stable) 


1  ••commandHandle 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

••dropDBLException 

M 

M(= 
) 

See  subparameter(s)  below. 

•••commandHandle- 
Unknown 

S 

S(= 
) 

No  additional  limitation. 

6.1.8.3.3  R-DropDBL  error 


Table  38  -  Parameters  for  R-DropDBL  error 


Parameter 

rap 

cnf 

Limitation 

operationID 

M 

M(= 
) 

An  INTEGER  with  value  greater  than 
0. 

duplicateOperationID 

S 

S(= 
) 

No  additional  limitation. 

invalidSequence 

S 

See  sub|3arameter(s)  below. 

•diagnosticlnformation 

U 

No  additional  limitation. 

operationAborted 

S 

S(= 

) 

See  subparameter(s)  below. 

•errorType(default  value: 
transient) 

M 

M(= 
) 

No  additional  limitation. 

•diagnostici  nf ormation 

U 

C(= 
) 

A  VisibieString,  from  1  through  254 
characters  long. 

operationCanoelled 

S 

S(= 
) 

No  additional  limitation. 

serviceNotNegotiated 

S 

S(= 
) 

No  additional  limitation. 
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6.2      Limits  for  common  parameters 

This  dause  describes  the  parameters  of  the  common  RDA  Types,  those  shared  by  more  than  one  RDA 
Service. 

Table  39  describes  the  parameters  for  SQLDataTypeDescriptor. 
Table  40  describes  the  parameters  for  SQLDBI^ception. 

Table  41  describes  the  parameters  for  SQLValue.  The  range  of  values  for  each  type  of  dataltem  in  this 
table  is  implied  by  the  values  of  the  parameters  of  the  corresponding  type  of  SQLDataTypeDescriptor  in 
Table  39. 


6.2.1  SQLDataTypeDescriptor 


Table  39  -  Parameters  for  SQLDataTypeDescriptor 


Parameter 

req 

ind 

rsp 

cnf 

Limitation 

nullable  (default 
value:  true) 

M 

M(= 
) 

No  additional  limitation. 

colName 

M 

M(= 
) 

A  VisibieString,  from  1 
through  18  characters 
long. 

typeDescriptor 

M 

M(=) 

M 

M(= 
) 

See  choice(s)  below. 

•characterType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
below. 

••charSet 

U 

C(=) 

U 

C(=) 

An  OBJECT  IDENTIFIER, 
from  2  through  16 
elements  long. 

••length 

M 

M(=) 

M 

M(= 
) 

An  INTEGER  with  value 
from  1  through  240.  It 
represents  the  maximum 
number  of  characters  in 
the  data  value.  Trailing 
(padded)  spaces  are 
included  in  the  length,  but 
a  trailing  null  byte  is  not. 

••fixedLength- 
Encoding 

M 

M(=) 

M 

M(= 
) 

No  additional  limitation. 

•numericType 

S 

S(=) 

8 

S(=) 

See  subparameter(s) 
below. 
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1  Parameter 

req 

ind 

rsp 

cnf 

Limitation  | 

1  ••precision 

M 

M(=) 

M 

M(= 
) 

This  parameter  sliali  1 
contain  a  value  within  the  | 
range  of  1  through  15.  | 

1  ••scale 

M 

M(=) 

M 

M(= 

) 

This  parameter  shall  | 
contain  a  value  within  the  | 
range  of  0  through  the  | 
value  of  precision.  { 

•decimalType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
below. 

••precision 

M 

M(=) 

M 

M(= 
) 

This  parameter  shall 
contain  a  value  within  the 
range  of  1  through  15. 

••scaie 

M 

M(=) 

M 

M(= 
) 

This  parameter  shall 
contain  a  value  within  the 
range  of  0  through  the 
value  of  precision. 

•integerType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
t>elow. 

••precision 

M 

M(=) 

M 

M(= 
) 

If  precisionBase  is 
decimal,  precision  must 
be  in  the  range  1  through 
9.  If  precisionBase  is 
binary,  precision  must  be 
in  the  range  1  through  31 . 

••precisionBase 

M 

M(=) 

M 

M(= 
) 

No  additional  limitation. 

•smalllntType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
below. 

••precision 

M 

M(=) 

M 

M(= 
) 

If  precisionBase  is 
decimal,  precision  must 
be  in  the  range  1  through 
4.  If  precisionBase  is 
binary,  precision  must  be 
in  the  range  1  through  15. 

••precisionBase 

M 

M(=) 

M 

M(= 
) 

No  additional  limitation. 

•floatType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
below. 
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1  Parameter 

req 

ind 

rsp 

cnf 

Limitation 

••mantissa- 
Precision 

M 

M(=) 

M 

M(= 
) 

An  INTEGER  with  value 
from  1  through  20. 

••maxExponent 

M 

M(=) 

M 

M(= 
) 

An  INTEGER  with  value 
from  0  through  38. 

•realType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
t^elow. 

1  ••mantissa- 
1  Precision 

M 

M(=) 

M 

M(= 
) 

An  INTEGER  with  value 
from  1  through  20. 

1  ••maxExponent 

M 

M(=) 

M 

M(= 
) 

An  INTEGER  with  value 
from  0  through  38. 

•double- 
PrecisionType 

S 

S(=) 

S 

S(=) 

See  subparameter(s) 
below. 

••mantissa- 
Precision 

M 

M(=) 

M 

M(= 
) 

An  INTEGER  with  value 
from  1  through  30. 

1  ••maxExponent 

M 

M(=) 

M 

M(= 
) 

An  INTEGER  with  value 
from  0  through  38. 

6.2.2  SQLDBLException 

Table  40  -  Parameters  for  SQLDBLException 


Parameter 

rsp 

cnf 

Limitation 

sQLSTATE 

C 

C(=) 

No  additional  limitation. 

sQLCODE 

C 

C(=) 

No  additional  limitation. 

sQLErrorText 

u 

C(=) 

A  VisibleString  from  1  through  254 
characters  long. 

6.2.3  SQLValue 
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Table  41  -  Parameters  for  SQLValue 


Parameter 

req 

ind 

rsp 

cnf 

Limitation 

dataltem 

U 

C(=) 

U 

C(= 

) 

See  choice(s)  below. 

•characterltem 

S 

S{=) 

s 

S(=) 

An  OCTET  STRING  from 
1  through  240 
characters. 

•numericltem 

s 

S(=) 

s 

S(=) 

An  INTEGER  with 
absolute  value  less  than 
10**15.  Note  that  the 
maximum  requires  a  7- 
octet  INTEGER  value. 

•decimalltem 

s 

S(=) 

s 

S(=) 

An  INTEGER  with 
absolute  value  less  than 
10**15.  Note  that  the 
maximum  requires  a  7- 
octet  INTEGER  value. 

•integerltem 

s 

S(=) 

s 

S(=) 

An  INTEGER  with 
absolute  value  less  than 
10**9,  if  precisionBase  is 
decimal.  An  INTEGER 
with  absolute  value  less 
than  2**31.  If 
precisionBase  is  binary. 

•smalllntltem 

s 

S(=) 

s 

S(=) 

An  INTEGER  with 
absolute  value  less  than 
10**4,  if  precisionBase  is 
decimal.  An  INTEGER 
with  absolute  value  less 
than  2**15,  if 
precisionBase  is  binary. 

•floatltem 

s 

S(=) 

s 

S(=) 

A  REAL  with  the  value  0 
or  absolute  value  in  the 
range  10**-38  through 
10**38  inclusive. 

•realltem 

s 

S(=) 

s 

S(=) 

A  REAL  with  the  value  0 
or  absolute  value  in  the 
range  10**-38  through 
10**38  inclusive. 
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1  Parameter 

req 

ind 

rsp 

cnf 

Limitation 

•double- 
Precisionitem 

S 

S(=) 

S 

S(=) 

A  REAL  witii  the  value  0 
or  al3Soiute  value  in  the 
range  10**-38  through 
10**38  Inclusive. 

indicator 

U 

C(=) 

U 

C(= 
) 

No  additional  limitation. 

6.3     Other  limits  and  agreements 


6.3.1       Operation  limits  and  agreements 

Operation  limits  and  agreements  follow: 

a)  OlW-compliant  RDA  Implementations  shall  confomi  to  the  following  agreements  stated  in  part 
5,  Upper  layers: 

1)  the  specific  ASE  requirements  stated  in  clause  13.8,  Remote  Database  Access;  and 

2)  all  other  agreements  that  pertain  to  the  Association  Control  Service  Element, 
Presentation,  and  Session,  including  those  for  ASN.l  encoding; 

b)  OlW-compiiant  RDA  implementations  shall  be  able  to  process  at  a  minimum  RDA  Application 
Protocol  Data  Units  of  30,000  octets.  It  is  recommended,  however,  that  Presentation  user  data  not 
be  restricted  in  size; 

c)  The  maximum  number  of  outstanding  RDA  operations  is  32; 

d)  If  an  RDA  server  receives  an  abort  event  after  an  R-BeginTransaction  Indication  and  before  an 
R-Commit  indication,  then  it  should  roll  back  the  cun-ent  transaction; 

e)  As  a  minimum,  the  character  set  ISO  8859-1  shall  be  supported.  The  OlW-defined  object 
identifier  for  this  character  set  is  : 

{  iso  (1)  identified-organization  (3)  oiw  (14) 
rda-slg  (9)  character-sets  (1)  oiw-latin-1  (1)  abstract-syntax  (1)  } 

NOTE  -  This  object  identifier  will  be  deprecated  at  such  time  that  ISO  defines  an  object  identifier  for  ISO  8859- 
1. 
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6.3.2       Recommended  praetices 

An  implementation  should  document  any  limitatton  on  the  number  of  schema  statements  that  the  server 
permits  within  a  single  transaction.  For  maximum  interoperability,  a  dlent  should  never  mix  schema 
statements  and  data  statements  within  a  transaction  arKi  should  restrict  the  number  of  schema  statements 
within  a  transactton  to  one. 


6.4     Rules  for  Profiles 

An  implementation  conformant  to  a  profile  shall  implement  all  the  functional  units  of  that  profile;  it  may 
CKJditionaliy  implement  other  functional  units  without  being  nonconformant. 

If  a  functional  unit  is  included  in  a  profile,  all  the  services  of  that  functional  unit,  as  specified  in  the  ISO/IEC 
9579-1  and  9579-2.  shall  be  included. 

An  implementation  conforming  to  a  given  profile  may  accept  a  dialogue  whose  functional  units  conform  to 
a  different  profile  without  being  nonconformant. 


6.4.1       Application  contexts 

This  sutx^lause  specifies  agreements  that  apply  to  individual  application  contexts. 


6.4.1.1        RDA  basic  application  context 

This  subclause  specifies  agreements  that  apply  to  the  RDA  Basic  Application  Context. 


6.4.1.2  Profiles 

This  subclause  specifies  which  functional  units  combine  to  form  each  profile. 


6.4.1.2.1  Rationale 

The  minimum  requirement  is  to  be  able  to  execute  SQL  Statements.  Therefore  all  profiles  include  the 
"Immediate  Execution  DBL*  functional  unit,  and  one  profile  (Immediate  Execution)  includes  just  this  minimum 
capability. 

Additional  capabilities  may  t>e  required  for  defining  and  invoking  DBL  statements.  Therefore  the  "Stored 
Execution  DBL"  functional  unit  is  required  only  in  a  separate  profile  (Stored  Execution)  defined  specifically 
for  this  capability. 

For  the  RDA  Control  Services,  executing  control  services  on  the  current  dialogue  requires  different  and 
probably  simpler  capabilities  than  executing  control  services  on  other  dialogues.  Therefore  additional  profiles 
are  defined  for  controlling  other  dialogues. 
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The  R-Status  Service  implies  only  Inquiry  about  the  controlled  dialogue.  whHe  the  R-Cartcel  Service  requires 
the  ability  to  modify  the  controlled  dialogue.  Since  different  authorization  or  access  control  permissions  may 
be  required,  It  is  useful  to  separate  R-Status  from  R-Cancel.  Therefore  two  separate  profiles  (Status  and 
Cancel)  are  defined  for  controlled  dialogue  capabilities. 

Since  an  implementation  may  include  functional  units  and  services  beyond  those  required,  or^y  this 
minimum  set  of  four  profiles  is  defined. 

6.4.1.2.2  Immediate  Execution 

This  profile  requires  support  of  immediate  execution  of  SQL  Statements.  It  requires  the  foilowing  functional 
units: 

a)  dialogue  initialization; 

b)  dialogue  termination; 

c)  transaction  management; 

d)  resource  handling;  and 

e)  immediate  execution  DBL 

6.4.1.2.3  Stored  execution 

This  profile  requires  support  of  execution  of  stored  SQL  Statements.  It  requires  the  following  functional 
units: 

a)  dialogue  initialization; 

b)  dialogue  termination; 

c)  transaction  management; 

d)  resource  handling; 

e)  immediate  execution  DBL;  and 

f)  stored  execution  DBL 

6.4.1.2.4  Status 

This  profile  requires  support  of  the  R-Status  service  on  other  dialogues.  It  requires  the  following  functional 
units: 

a)  dialogue  initialization,  specifically  Including  the  foilowing  parameters: 
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1)  controlSefviceDataRequested;  and 

2)  controlSefviceData; 

b)  dialogue  termination; 

c)  transaction  management; 

d)  status,  specifically  including  the  following  parameters: 

1)  controlledDialogue; 

e)  resource  handling;  and 

f)  immediate  execution  DBL 

6.4.1.2.5  Cancel 

This  profile  requires  support  of  the  R-Cancel  service  on  other  dialogues.  It  requires  the  following  functional  | 
units: 

a)  dialogue  initialization,  specifically  including  the  following  parameters: 

1)  contrdServiceDataRequested;  and 

2)  contrdServiceData;  : 

b)  dialogue  termination; 

c)  transaction  management;  | 

d)  cancel,  specifically  including  the  following  parameters: 

1)  controlledDialogue; 

e)  resource  handling;  and  . 

f)  immediate  execution  DBL 

6.4.2       RDA  TP  application  context 
No  text. 
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Annex  A  (normative)  

RDA  SIG  object  identifiers 

Table  42  lists  the  object  identifiers  defined  by  tills  part  of  tiie  implementation  Agreements. 
 Table  42  -  Object  ldentHier»  defined  by  RDA 


Object  Identifier 

Reference 

iso  (1)  identified-organization  (3)  oiw  (14) 
rda-sig  (9)  cliaracter-sets  (1)  oiw-iatin-1  (1) 
at>stract-syntax  (1) 

6.3.1 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Manufacturing  Message 
Specification  (MMS)  Special  Interest  Group  (MMSSIG)  of  the  Open  Systems  Environment  Implementors' 
Workshop  (OIW).  See  Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  No  significant 
technical  change  has  occurred  in  this  part  since  it  was  previously  presented. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  20  -  Manufacturing  Message  Specification  (MMS) 


0  Introduction 

This  section  defines  Implementors  Agreements  based  on  Manufacturing  Message  Specification  (MMS),  as 
defined  in  ISO/IEC  9506.  iSO/iEC  9506  lias  two  parts.  Part  1  defines  the  Virtual  Manufacturing  Device 
(VMD).  Its  subordinate  abstract  objects,  and  the  services  on  these  objects.  Part  2  defines  the  protocol. 
Future  parts  may  define  companion  standards. 

MMS.  as  described  in  ISO/IEC  9506,  is  based  on  the  following  ISO  documents:  ACSE  Service  and  Protocol 
(ISO  8649,  ISO  8650).  Presentation  Service  and  Protocol  (ISO  8822.  ISO  8823),  ASN.I  Abstract  Syntax 
Notation  and  Basic  Encoding  Rules  (ISO  8824.  ISO  8825).  and  Session  Service  and  Protocol  (ISO  8326,  ISO 
8327).  These  services  and  protocols  are  defined  architecturally  in  the  OSi  Reference  Model  (ISO  7498). 
These  agreements  provide  detailed  guidance  for  the  implententor,  and  eliminate  ambiguities  in 
interpretations. 

An  A-Profile  based  on  MMS  and  these  agreements  can  be  used  over  any  T-Profile  (see  ISO  TR  10000) 
specifying  the  OSI  connection-mode  transport  service,  or  the  transport  profiles  used  in  support  of  MAP 
(Manufacturing  Automation  Protocol),  TOP  (Technical  and  Office  Protocols),  or  US  GOSiP. 


1  Scope 


2    Field  of  Application 


2.1  General 

Work  on  Implementation  agreements  will  proceed  in  phases  based  upon  grouping  of  services  and/or 
contexts.  Implementations  are  not  constrained  from  Implementing  services  or  contexts  not  addressed  by 
the  current  set  of  stable  agreements.  Future  phases  of  work  may  affect  such  implementations. 


2.2      Phase  1  agreements 

These  agreements  will  be  based  on  a  subset  of  MMS  services  and  protocol  listed  in  table  1  and  defined  in 
ISO/IEC  9506-1  and  ISO/IEC  9506-2. 
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Table  1  -  Phase  1  Services 


Initiate 
Conclude 
Reject 
Abort 

Status 

GetNameList 

Identify 

Unsol i  ci  t edS t atus 
GetCapabilityList 

Ini t i at eDownloadSequence 

DownloadSegment 

Termi nat eDownloadSequence 

mi  t  i  at  eUploadSequence 

UploadSegment 

TerminateUploadSequence 

DeleteDomain 

Ge t Doma i nAt t r i bu t es 

Read 
Write 

Informat ionReport 
GetVariableAccessAttributes 

Input 
Output 

CreateProgramlnvocation 

DeleteProgriunlnvocation 

Start 

Stop 

Resume 

Reset 

Kill 

GetProgramlnvocat ionAttr ibutes 
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3    Normative  References 

[1]       ISO/IEC  9506-1 : 1 990  -  Industrial  automation  systems  -  Manufacturing  Message  Specification  Part 
1:  Service  definition 

[2]       ISO/IEC  9506-2: 1 990  -  Industrial  automation  systems  -  Manufacturing  Message  Specification  Part 
2:  Protocol  specification 


4  Definitions 

The  definitions  given  in  ISO/IEC  9506-1  are  applicable  to  this  document. 
In  addition  the  following  definitions  are  used  in  this  document: 

MMS  implementation  a  term  used  to  describe  a  system  which  conforms  to  ISO/IEC  9506,  acting 
either  as  client  or  server,  when  it  is  unnecessary  to  distinguish  between  the  MMS-user 
and  the  MMS-provider. 

MMSpdu  Any  valid  value  of  the  MMSpdu  abstract  data  type  as  defined  in  Gause  7  of  ISO/IEC 

9506-2,  except  for  the  initiate-RequestPDU,  initiate-ResponsePDU,  and  initiate-ErrorPOU 
choices,  encoded  in  the  negotiated  transfer  syntax. 


I  5    Corrigenda  and  addenda 

1   (Refer  to  Working  Agreements.) 


!  6  Status 

Il  (Refer  to  Working  Agreements.) 


7    General  agreements 
I  7.1      Max  supported  PDU  size 

I  The  max_mms_pdu_size  is  defined  as  the  maximum  number  of  octets  in  an  MMSpdu  encoded  using  the 
negotiated  transfer  syntax  This  size  shall  apply  to  all  MMSpdu's  with  the  exception  of  the  initiate-Request 
PDU,  initiate-Response  PDU,  and  initiate-Error  PDU.  The  max  mms  pdu  size  shall  be  negotiated  during 
connection  initiation  using  the  Local  Detail  Calling  and  Local  Detail  Called  parameters  of  the  MMS  initiate 
service. 

The  negotiated  max_mms_pdu_size  shall  be  applied  as  follows: 


II 


3 


PART  20  -  MMS 


D@c@mber  1992  (Stable) 


a)  Any  received  MMSpdu  whose  length  is  less  than  or  equal  to  the  negotiated  max_mms_pdu_size 
shall  be  properly  parsed  and  processed. 

b)  An  MMS  implementation  should  not  send  an  MMSpdu  whose  size  exceeds  the  negotiated 
max_mms_pdu_size.  If  an  MMS  implementation  sends  an  MMSpdu  that  exceeds  the  negotiated 
max_mms_pdu_size,  then  it  shall  be  prepared  to  receive  a  reject  pdu.  Should  an  MMS 
implementation  receive  an  MMSpdu  that  exceeds  the  negotiated  max_mms_pdu_size,  it  shall  either 
reject  the  MMSpdu  or  accept  the  MMSpdu  as  if  no  size  violation  had  occurred  and  perform  the 
expected  processing. 

c)  If  an  MMS  implementation  is  unable  to  send  a  service  response  because  the  response  would 
exceed  the  max_mms_pdu_size,  then  it  shall  return  a  Service  response  (-)  with  an  error  class  of 
SERVICE  and  an  error  code  of  OTHER. 

d)  When  rejecting  an  MMSpdu  because  ft  exceeds  the  negotiated  max_mms_pdu_slze,  an  MMS 
implementation  shall  use  a  Reject  PDU  Type  of  PDU-ERROR  and  a  Reject  Code  of  INVALID-PDU 
in  the  resulting  reject  pdu. 


7.2  FileName 

Restrictions  for  the  use  of  the  type  FileName  in  the  MMS  Abstract  Syntax  are  specified  in  section  9.1  of  part  I 
9  of  these  agreements. 


8     Service-specific  agreements 


8.1      Environment  and  general  management 
8.1.1       Initiate  i 


8.1.1.1        Negotiation  of  MMS  abstract  syntaxes 

On  the  A-ASSOCIATE  response,  the  MMS  responder  shall  not  accept  more  than  one  presentation  context  \ 
derived  from  an  MMS  abstract  syntax.  For  this  agreement,  the  term  "MMS  abstract  syntax"  shall  represent 
an  abstract  syntax  from  the  set  containing  the  abstract  syntax  defined  in  clause  19  of  I  SO/I  EC  9506-2  and 
abstract  syntaxes  defined  by  MMS  companion  standards. 

NOTE  -  There  are  technical  problems  with  describing  operation  in  multiple  MMS  abstract  syntaxes  over  a 
single  aissociation.  These  problems  have  been  identified  as  of  9/90,  and  form  the  basis  of  the  prior  agreement. 
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8.1.1.2 


Max  serv  outstandmg 


An  MMS  Implementation  which  intends  to  confonrs  only  with  the  Client  Confonnance  Requirements  for 
Requester  CBBs  shall: 

a)  propose  one  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Called  parameter 
In  the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  one  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Calling  parameter  in 
tfie  Initiate  seivlce  when  receiving  the  applicationi  associatbn  initiation  (called). 

An  MMS  Implementation  which  intends  to  cortlorm  to  one  or  more  Server  Conformance  Requirements  for 
Responder  CBBs  shall: 

a)  propose  one  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Calling  parameter 

in  the  Initiate  service  when  ioitiatiog  the  application  association  (calling); 

b)  offer  one  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Called  parameter  in 
the  Initiate  service  when  receiving  the  application  association  initiation  (called). 


The  local  detail  calling  parameter  in  the  initiate  request  primitive  shaSS  specify  the  max_mms_pdu_size 
guaranteed  to  be  supported  by  the  calling  MMS  Implementation.  If  the  local  detail  calling  parameter  is 
absent  from  the  request  primitive,  then  the  catling  MMS  implementation  guarantees  support  for  an  unlimited 
max_mms_pdu__si2e. 

If  present  in  the  request  or  indication  primitives,  the  local  detail  calling  parameter  shall  not  be  less  than  64; 
however,  it  Is  recommended  that  at  least  512  octets  be  supported. 


8.1.1.4        Local  detail  called 


The  local  detail  called  parameter  in  the  initiate  response  shall  specify  the  negotiated  max_mms_pdu_slze 
for  the  application  association. 

If  the  local  detail  calling  parameter  was  omitted  in  the  indication  primitive,  then  the  local  detail  called 
parameter: 

a)  may  be  omitted  from  the  response,  indicating  that  the  calling  MMS  implementation  and  the 
called  MMS  implementation  are  prepared  to  support  an  unbounded  max_mms_pdu_size; 

b)  may  be  specified  in  the  response,  Indicating  a  requirement  to  support  the  specified  value  for 
max_mms_pdu_size. 

If  the  local  detail  calling  parameter  was  included  in  the  request,  then  this  parameter  shall  t>e  present  in  the 
response  and  its  value  shall  be  less  than  or  equal  to  the  value  of  the  local  detail  calling  parameter  of  the 
request. 


8.1.1.3 


Local  detail  calling 


5 


PART  20  -  MMS 


December  1992  (Stable) 


If  present  in  the  response,  the  local  detail  called  parameter  shall  not  be  less  than  64;  however,  it  is 
recommended  that  at  least  512  octets  be  supported. 


8.2      VMD  support 


8.3      Domain  management 


8.3.1       List  of  capabilities 

Only  one  capability  shall  be  described  in  each  Visible  String  of  the  SEQUENCE  OF. 


8.3.2       Initiate  Download  Sequence  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 

The  syntax  and  semantics  of  the  capabilities  shall  be  defined  by  the  Server  in  the  PICS.  Any  deviation  from 
the  defined  syntax  and  semantics  shall  be  grounds  for  the  Server  to  return  a  service  error  with  Error  Class 
=  RESOURCE  and  En-or  Code  =  CAPABILITY-UNKNOWN. 


8.3.3       Download  Segment  service 

A  client  that  receives  a  Download  Segment  indication  after  issuing  a  Download  Segment  Result(+)  with  the 
MoreFollows  parameter  equal  to  FALSE  or  after  issuing  a  Download  Segment  Result(-)  shall  issue  either  a 
sen/ice  en-or,  specifying  an  Error  Qass  =  SERVICE  and  an  Error  Code  =  PRIMITIVES-OUT-OF-SEQUENCE. 
or  an  Abort  request. 


8.3.4       Terminate  Download  Sequence  service 

If  a  client  receives  a  Terminate  Download  Sequence  indication  in  which  the  Discard  parameter  is  absent  and 
the  client  has  not  issued  a  Download  Segment  response  with  the  More  Follows  parameter  =  FALSE  for  that 
Domain,  it  shall  t>ehave  as  if  it  had  received  a  Terminate  Download  Sequence  indication  with  the  Discard 
parameter  present  with  en-or  class  =  VMD-STATE  and  error  code  =  DOMAIN-TRANSFER-PROBLEM.  It  is 
then  up  to  the  client  application  to  determine  the  true  state  of  the  Domain  and  take  any  recovery  action. 


8.3.5       Initiate  Upload  Sequence  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 
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8.3.6  Upload  Segment  service 

A  server  that  receives  an  Upload  Segment  indication  for  an  Upload  State  Maciilne  for  which  it  has  issued 
an  Upload  Segnient  Result(-)  or  an  Upload  Segment  Result(+)  with  the  MoreFollows  parameter  equal  to 
FAL^E,  shall  issue  either  a  service  enror,  specifying  an  Enror  Class  =  SERVICE  and  an  En'or  Code  = 
PRIMITIVES-OUT-OF-SEQUENCE,  or  an  Abort  request. 

8.3.7  Get  Domain  Attributes  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 

8.3.8  Get  Capability  List  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 

8.4      Program  Invocation  management 

8.4.1  start  service 

A  ProgramlnvocationState  of  non-existent  shall  t>e  retumed  in  a  Result(-)  when  a  request  to  Start  a  non- 
^dstent  Program  Invocation  is  received. 

8.4.2  Stop  service 

A  ProgramlnvocationState  of  non-existent  siiall  be  retumed  in  a  Result(-)  when  a  request  to  Stop  a  non- 
existent Program  Invocation  is  received. 


8.4.3       Resume  service 

A  ProgramlnvocationState  of  non-existent  shall  be  returned  in  a  Result(-)  when  a  request  to  Resume  a  non- 
existent Program  Invocation  is  received. 


8.4.4       Reset  service 

A  ProgramlnvocationState  of  non-existent  shall  be  retumed  in  a  Result(-)  when  a  request  to  Reset  a  non- 
existent Program  Invocation  is  received. 


7 


PART  20  -  MMS 


December  1992  (Stable) 


8.5 


Variable  access 


8.5.1 


Scattered  access 


It  is  strongly  recommended  that  for  services  which  use  variable  access,  a  Variable  Ust  Name  or  List  of 
Variable  be  used  Instead  of  Scattered  Access. 

No  Implementations  shall  t>e  required  to  propose  or  accept  the  VSCA  Parameter  CBB. 

8.5.2       Floating  point 

it  is  strongly  recommended  for  services  which  use  floating  point  types  or  values,  that  the  choice  of  floating- 
point in  the  Data  and  TypeSpecification  productions  be  used  instead  of  the  real  choice. 

No  implementations  shall  be  required  to  propose  or  accept  the  REAL  parameter  CBB. 

8.6  Semaphore  management 

Semaphore  services  are  not  considered  in  Phase  1 . 

8.7  Operator  communication 

No  Operator  Communication  agreements  have  been  identified  to  date. 

8.8  Event  management 

Event  Mariagement  services  are  not  considered  in  Phase  1 . 

8.9  Journal  management 

Journal  Management  services  are  not  considered  in  Phase  1 . 
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Annex  A  (normative)  

Backwards  compatibility  agreements 


A.1  Introduction 

There  is  an  installed  base  of  real  DIS  9506  based  implementations.  Providing  support  for  application 
connectivity  to  both  DIS  and  IS  Is  desired  as  a  migration  strategy.  These  implementation  agreements  will 
allow  IS  based  Implementations  to  Interoperate  with  DIS  based  implementations  as  described  in  ANNEX  B. 
To  achieve  this  t)ackwards  compatibility,  the  IS  Implementation  shall  support  all  of  the  agreements  in  this 
section. 

It  was  found  that  the  Abstract  Syntax  name  object  identifiers  of  both  DIS  and  IS  were  Identical.  Therefore, 
the  use  of  zero  as  the  version  number  allows  differentiation  t)etween  an  IS  and  a  DIS  based  Implementation. 
Since  the  abstract  syntax  name  object  Identifier  of  any  companion  standard  is  different  from  that  used  by 
the  DIS  implenrantations,  DIS  implementations  cannot  interoperate  with  IS  based  Implementations  in  a 
companion  standard  context. 

NOTES 

1  The  value  of  zero  is  a  valid  value  for  this  parameter  in  the  DIS  and  not  in  the  IS. 

2  There  are  three  typ>es  of  implementations  when  considering  MMS  backwards  compatibility. 

i    IMP-1 :  An  implementation  based  on  DIS  9506  as  described  in  Annex  B; 

IMP-2:  An  implementation  based  on  IS  9506  with  no  backwards  compatibility  agreenients 

applied; 

IMP-3:  An  Implementation  based  on  IS  9506  which  includes  the  backwards  compatibility 

agreements  of  this  annex.  Such  an  implementation  can  dynamically  negotiate  to 
Interoperate  with  an  IMP-1.  an  IMP-2.  or  an  IMP-3  implementation. 

1    Since  the  value  of  the  minor  version  number  is  zero  for  DIS-based  implementations,  and  Is  one  or  greater 
for  implementattons  of  ISO/IEC  9506,  this  value  can  be  used  to  differentiate  between  IMP-1  and  IMP-2.  An 
I    IMP-3  system  can  Interoperate  with  either  of  these  systems.  If  an  IMP-3  is  the  Calling  system,  it  will  offer  a 
!    value  of  one  (or  greater)  for  the  proposed  version  number.  An  IMP-1  system  will  respond  with  a  value  of  the 
negotiated  verston  number  of  zero,  using  the  negotiation  procedure  defined  in  ISO/IEC  9506.  The  IMP-3 
system  will  accept  this  response.  If  the  IMP-3  system  is  the  Called  system  and  has  received  an  Initiate 
request  with  a  value  of  zero  for  the  proposed  version  number  (from  an  IMP-1  system),  It  will  respond  with 
a  value  of  zero  for  the  negotiated  version  number.  By  following  this  procedure,  an  IMP-3  can  interoperate 
j    with  an  IMP-2  or  with  another  IMP-3  viewed  as  an  IMP-2.  After  association  context  establishment,  an  IMP-3 
i    system  shall  behave  as  either  an  IMP-1  or  an  IMP-2  system  as  appropriate  on  that  particular  association. 
The  remainder  of  this  section  describes  additional  agreements  which  change  an  IMP-2  implementation  into 
an  IMP-3  implementation. 
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A.2     Backwards    compatibility    agreements    for    calling  MMS 
implementations 

A  calling  MMS  Implementation  shall  be  capable  of  receiving  and  supporting  a  negotiatedVersionNumber  « 
parameter  in  the  Initiate  Service  confirm  of  zero. 

A  calling  MMS  Implementation  which  has  received  a  negotiatedVersionNumber  parameter  in  the  initiate  ; 
Service  confirm  of  zero  shall  support  the  modifications  described  in  A.4. 

A  calling  MMS  Implementation  shall  be  capable  of  receiving  an  Application  Context  Name  parameter  value  j 
appropriate  to  an  IMP-1  or  IMP-2  in  the  A-Associate  confirm.  | 

A  calling  MMS  implementation  which  has  received  a  negotiatedVersionNumber  of  zero  sfiall  be  capable  of  j 
receiving  and  supporting  an  Initiate  Response  which  has  been  encoded  according  to  the  modifications  | 
described  in  Appendix  B.  specifically  the  capability  of  receiving  and  supporting  a  negotiatedParameterCBB 
containing  exactly  7  bits. 

If  a  calling  MMS  Implementation  receives  an  Initiate  confirm  primitive  with  a  negotiatedVersionNumber  i 
parameter  equal  to  zero,  the  calling  MMS  implementation  shall  support  the  VUS  conformance  building  block  | 
if  the  implementation  claims  support  for  any  service  which  contains  one  or  more  parameters  which  indicate 
the  VUS  CBB  in  its  service  definition. 

A.3     Backwards    compatibility    agreements    for    called  MMS 
implementations 

A  called  MMS  implementation  shall  be  capable  of  receiving  and  supporting  a  proposedVersionNumber 
parameter  in  the  initiate  Sen/ice  indication  of  zero.  | 

A  called  MMS  Implementation  which  has  received  a  proposedVersionNumber  parameter  in  the  Initiate  | 
Service  indication  of  zero  shall  support  the  modifications  in  A.4. 

A  called  MMS  Implementation  shall  be  capable  of  receiving  an  Application  Context  Name  parameter 
appropriate  to  an  IMP-1  or  IMP-2  in  the  A-Associate  indication. 

A  called  MMS  implementation  shall  be  capable  of  receiving  and  supporting  an  initiate  Request  which  has 
been  encoded  according  to  the  modifications  descrii3ed  in  Appendix  B,  specifically  the  capability  of  receiving 
and  supporting  a  proposedParameterCBB  containing  exactly  7  bits. 

If  a  called  MMS  implementation  receives  an  Initiate  indication  primitive  with  a  proposedVersionNumber 
parameter  equal  to  zero,  the  called  MMS  implementation  shall  support  the  VUS  confonnance  building  tiock 
if  the  implementation  claims  support  for  any  service  which  contains  one  or  more  parameters  which  indicate  ! 
the  VUS  CBB  in  its  service  definition. 
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A.4     General  backwards  compatibility  agreements 


A.4.1      VMD  logical  status 

If  the  current  VMD  State  Is  SUPPORT-SERVICES-ALLOWED  and  the  assodatbn  minor  version  number  Is 
zero,  then  the  vmdLoglcalStatus  parameter  shaH  have  a  value  of  STATE-CHANGES-ALLOWED  in  a  Status 
response  or  In  an  unsollcltedStatus  request. 
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Annex  B  (normative) 

DIS  9506  Modifications  Required  for  Backwards  Compatibility 
B.1  Introduction 

This  annex  is  an  integral  part  of  tliis  part,  it  documents  tlie  nfKxJiflcatlons  to  DiS  9506  required  to  describe 
implementations  for  which  the  agreements  of  this  part  provide  backwards  compatibility.  This  annex  as 
applied  to  DIS  9506  is  referred  to  as  Version  0. 


B.2  References 

[1]      MMS/1  Manufacturing  Message  Specification  -  ISO  DIS  9506  -  Sen/ice  Definition,  December  1987 

[2]      MMS/2  Manufacturing  Message  Specification  -  ISO  DIS  9506  -  Protocol  Specification,  December 
1987 

[3]      NBS  OSI  Implementors  Workshop  Agreements  -  December  1987 

B.3  General 

B.3.1       Implementation  base 

Version  0  is  l3ased  upon  Reference  [3]  in  B.2  as  it  applies  to  MMS. 
B.3.2       Rules  of  extensibility 

The  following  sentence  is  appended  to  the  last  paragraph  in  section  8.2.1.1.5.2  Proposed  Parameter  CBB 
and  the  last  paragraph  in  section  8.2.1.2.5.2  Negotiated  Parameter  CBB  of  DiS  9506-1. 

.  ,    'Any  additional  bits  shall  t)e  ignored." 

B.4     Modifications  to  tlie  protocol  definitions 
B.4.1       Page  39,  Section  7.5.2  of  DIS  9506-2 
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CHANGE 

reportEventEnrollmentStatus 

(60] 

IMPLICIT 

ReportEventEnrollaentStatua-Requeat , 

TO 

reportEventEnrollmentStatus 

[60] 

ReportEventEnrollaentStatus-Request , 

B.4.2      Page  49,  Section  7.6.4,  DIS  9506-2 


CHANGE 

Appl icat ionReference 
ap-title 

ap- i  nvoca t  i  on- i  d 
ae-quali£ier 
ae- i  nvoca t  i on- i  d 

: : =  SEQUENCE  { 

ISO-8650-ACSE-l.AP-title  OPTIONAL, 
ISO-86  50-ACSE-l.AP-invocat ion-id  OPTIONAL, 
ISO-8650-ACSE-l.AE-quali£ier  OPTIONAL, 
ISO-8650-ACSE-l.AE-invocat ion-id  OPTIONAL  } 

TO 

Appl i cat i onRe £e rence 
ap-title 

ap- i nvoca t i on- i d 
ae-quali£ier 
ae- i nvoca t  i  on- i  d 

: : =  SEQUENCE  { 

[0]  OBJECT  IDENTIFIER  OPTIONAL, 
[1]  INTEGER  OPTIONAL, 
[2]  INTEGER  OPTIONAL, 
[3]  INTEGER  OPTIONAL  } 

B.4.3       Page  95,  Section  12.2.1  of  DIS  9506-2 


CHANGE 

Structure  [2]  IMPLICIT  SEQUENCE  OF  SEQUENCE  { 
TO 

Structure       [2]  IMPLICIT  SEQUENCE  { 


B.4.4       Page  96,  Section  12.3.1  of  DIS  9506-2 
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CHANGE 

named 

[41 

IMPLICIT  SEQUENCE  { 

TO 

named 

[5] 

IMPLICIT  SEQUENCE  { 

B.4.5      Page  98,  Section  12.4.2  of  DIS  9506-2 


CHANGE 

general i  zed-t  ime 

[10] 

IMPLICIT 

General i  zedTime , 

TO 

generalized-time 

[11] 

IMPLICIT 

General i  zedTime , 

B.4.6      Page  138,  Section  15.14  of  DIS  9506-2 


CHANGE 

additionalDetail 

[9] 

IMPLICIT  EE-Additional-Detail  OPTIONAL 

TO 

addi  t  ionalDetai 1 

[9] 

EE-Additional-Detail  OPTIONAL 

B.4.7       Page  166,  Section  17.10  of  DIS  9506-2 


CHANGE  the  transfer  syntax  object  identifier  value  from 

{  iso    asnl(l)    basic-encoding(l)  } 
TO 

(  joint-iso-ccitt    asnl(l)    basic-encoding(l)  } 
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B.5.1  Filenames 

FNe  Names  are  specified  in  accordance  with  the  NBS  Implementors'  agreements  for  FTAM  Reference  [3] 
in  B.2. 


B.5.2      Identify  service 

in  the  Identify  service,  the  vendor,  model  and  revision  fields  may  be  of  any  length,  but  only  the  first  64. 16, 
and  16  octets  respectively  are  treated  as  significant. 


B.5.3      Initiate  service 

An  MMS  aient  wUi: 

a)  propose  1  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Called  parameter  in 
the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  1  or  greater  for  the  value  of  the  Negotiated  Max  Sen/  Outstanding  Calling  parameter  in  the 
Initiate  service  when  receiving  the  application  association  initiation  (called). 

An  MMS  Server  will: 

a)  propose  1  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Calling  param^er  In 
the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  1  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Called  parameter  in  the 
Initiate  service  when  receiving  the  application  association  initiation  (called). 


i  B.5.3.1        Minimum  segment  size 

iMMS  implementations  are  able  to  parse  and  process  51 2  octets  of  MMSpdu  as  they  are  encoded  in  ASN.  1 
basic  encoding  rules. 

I  B.5.3.2       Maximum  segment  size 

J  The  Max  Segment  Size  is  defined  as  the  maximum  number  of  octets  in  an  MMSpdu  encoded  using  the 
I  negotiated  transfer  syntax.  This  size  will  apply  to  all  MMSpdu's  with  the  exception  of  the  initiate-Request 
I  PDU.  initiate-Response  PDU,  and  the  initiate-Error  PDU.  The  max  segment  size  will  be  negotiated  during 
connection  initiatton  using  the  Proposed  Max  Segment  Size  and  Negotiated  Max  Segment  Size  parameters 
I  of  the  MMS  initiate  service. 
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The  Max  Segment  Size  will  be  applied  as  follows: 

a)  Any  received  MMSpdu  which  is  less  than  or  equal  to  the  Msx  Segment  Size  wll  be  properly 
parsed  and  processed; 

b)  An  MMS  implementatton  will  not  send  an  MMSpdu  whose  size  exceeds  the  Max  Segment  Size. 
B.5.4      Abstract  syntax  name 

The  ASN.1  dbiedt  identifier  value  for  the  abstract  syntax  name  wll  be  the  same  as  specified  on  page  166. 
section  17.10  of  DIS  9506-2. 

B.5.5      Application  context  name 

The  ASN.1  object  identifier  value  for  the  application  context  name  wHI  be  the  same  as  specified  on  page  166. 
section  17.11  of  DIS  9506-2. 

An  MMS  implementation  ignores  the  Application  Context  Name  In  the  A-Associate  indication  and  the  A- 
Associate  confirm. 

B.5.6      Minor  version  number 

The  Minor  Version  Numt)er  is  zero. 

B.6     Parameter  CBB  subset 

The  following  sut>set  of  MMS  Parameter  CBBs  were  considered  during  preparation  of  this  ann^ 

a)  STR1: 

b)  NEST; 

c)  VADR; 

d)  VNAM. 
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The  following  subset  of  MMS  services  were  considered  during  preparation  of  this  annex. 

Table  2  -  MMS  Service  Subset 


Initiate 

Output 

Conclude 

TakeControl 

Cancel 

RelinquishControl 

Status 

ReportSemaphoreStatus 

GetNameUst 

ReportPodSemaphoreStatus 

identify 

ReportSemaphoreEntryStatus 

UnsollcltedStatus 

CreatePrograminvocation 

GetCapaMltyUst 

DeleteProgramlnvocation 

InitlateOownloadSequence 

Start 

DownloadSegment 

Stop 

TenninateDownloadSequence 

Resume 

InltlateUploadSequence 

Reset 

UploadSegment 

Kill 

TenninateUploadSequence 

GetProgramlnv'OcationAttributes 

RequestOomainDownload 

ObtalnFiie 

RequestDonralnUpload 

GetEventConditlonAttributes 

LoadDonrtainContent 

ReportEventConditionStatus 

StoreDomalnContent 

GetAlarmSummary 

DeleteDomain 

ReadJoumal 

GetDomainAttributes 

WriteJoumal 

Read 

initializeJoumai 

Write 

CreateJoumai 

informationReport 

DeleteJoumal 

GetVariableAccessAttributes 

ReportJoumalStatus 

Input 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Worl<shop  Chair  of  the  Open 
Systems  Environment  Implementors'  Worl<shop  (OiW). 
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Future  changes  and  additions  to  this  version  of  these  implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strucl<out.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Foreword 

This  part  6f  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture  (ODA) 
Special  Interest  Group  (SIG)  of  the  Open  Systems  Environment  Implementors'  Woricshop  (OIW). 
Development  of  this  document  application  profile  has  been  done  in  liaison  with  several  organizations.  These 
include  the  DoD  Computer-aided  Acquisition  and  Logistic  Support  (CALS)  Office.  Navy's  David  Taylor 
Research  Center,  and  the  ad-hoc  Tiling  Tasi<  Group. 

This  document  application  profile  is  intended  to  be  suitable  for  the  interchange  of  large  format  raster  images 
which  may  be  annotated  with  character,  raster,  or  geometric  revisions. 

This  part  contains  four  annexes: 

a)  annex  A  (normative):  Amendments  and  corrigenda; 

b)  annex  B  (informative):  Recommended  practices; 

c)  annex  C  (informative):  References  to  other  standards  and  registers; 

d)  annex  D  (informative):  Supplementary  information  on  attributes. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part.  Deleted  and  replace  text  will  be  shown  as  strucl<out.  New  and  replacement  text  will  be  shown  as 
shaded. 

This  part  uses  a  convention  of  double  and  single  quotes  that  has  been  established  by  ISO  for  use  in  the 
ODA  base  standard  and  related  document  application  profiles.  The  convention  is  to  use  within  the  text 
double  quotes  to  accentuate  ODA  attribute  names  arid  single  quotes  to  accentuate  values  for  those 
attributes. 
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0  Introduction 

This  is  the  definition  of  a  specification  for  an  Open  Document  Architecture  (ODA)  Document  Application 
Profile  (DAP)  named  ODA  Image  DAP.  This  DAP  is  suitable  for  interchanging  documents  in  formatted  form. 
The  documents  contain  primarily  raster  graphics  Images  but  may  also  contain  character  and  geometric 
graphics  content  portions. 

There  are  two  DAP  object  identifiers  supporting  this  DAP  with  the  only  difference  being  in  the  encoding  of 
the  data  stream.  One  uses  the  ASN.1  based  ODIF  encoding.  The  other  uses  the  SGML/SDIF  based  ODL 
encoding.  When  this  document  refers  to  this  profile,  it  is  referring  to  this  specification  regardless  of  which 
DAP  identifier  nnay  be  selected  to  create  the  data  stream. 

The  DAP  is  defined  in  accordance  with  ISO  8613-1  and  CCITT  T.41 1  and  follows  the  standardized  proforma 
and  notation  defined  in  ISO  8613-1  Annex  F.  The  DAP  is  based  on  ODA  as  defined  in  ISO  8613  and  the 
Tiled  Raster  Graphics  Addendum  to  ISO  8613,  Part  7. 


1     Scope  and  field  of  applications 

This  DAP  specifies  an  interchange  format  suitable  for  transfer  of  structured  documents  between  equipment 
designed  for  raster  processing.  The  documents  supported  by  this  DAP  are  based  on  a  paradigm  of  an 
electronic  engineering  drawing  or  illustration.  Such  documents  contain  one  or  more  pages.  Each  page 
consists  of  a  base  image  in  the  form  of  a  bi-tonal  raster  graphics,  character,  or  geometric  graphics  content. 
This  base  image  may  be  further  annotated  with  character,  raster  graphics  or  geometric  graphics  content. 
These  latter  content  portions  serve  to  provide  revision  control  for  the  engineering  drawing  or  illustration. 
There  is  no  restriction  on  the  minimum  size  of  the  base  image. 

This  document  defines  a  DAP  that  allows  large  format  raster  documents  to  be  interchanged  in  a  fornr^tted 
form  in  accordance  with  ISO  8613. 

It  is  assumed  that,  when  negotiation  is  performed  by  the  sen/ice  using  this  DAP,  all  non-basic  values  are 
subject  to  negotiation. 

This  DAP  is  independent  of  the  processes  carried  out  in  an  end  system  to  create,  edit,  or  reproduce  raster 
documents.  It  is  also  independent  of  the  means  to  transfer  the  document  which,  for  example,  may  be  by 
means  of  communication  links  or  exchanged  storage  media. 

The  features  of  a  document  that  can  be  interchanged  using  this  DAP  fall  into  the  following  categories: 

a)  Page  format  features  -  these  concern  how  the  layout  of  each  page  of  a  document  will  appear 
when  reproduced; 

b)  Raster  graphics  layout  and  imaging  features  -  these  concern  how  the  document  content  will 
appear  within  pages  of  the  reproduced  document; 

c)  Raster  graphics  coding  -  these  concern  the  raster  graphics  representations  and  control 
functions  that  mal<e  up  the  document  raster  graphics  content. 
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2     Normative  references 

The  following  references  are  required  in  order  to  implement  this  DAP: 


2.1  ISO 

[I]  ISO  8613-1 : 1989,  Information  processing  -  Text  and  Off  ice  Systems;  Open  Document  Architecture 
(ODA)  arxi  Intercfiange  Format  -  Part  1:  Introduction  and  General  Principles; 

[2]  ISO  861 3-2 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  interchange  Format  -  Part  2:  Document  Structures', 

[3]  ISO  861 3-4  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  4:  Document  Profile; 

[4]  ISO  861 3-5  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  5:  Open  Document  Interchange  Format, 

[5]  ISO  861 3-6 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  6:  Character  Content  Architecture; 

[61  ISO  861 3-7 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  7:  Raster  Graphics  Content  Architectures; 

[7]  ISO  861 3-8 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  8:  Geometric  Graphics  Content  Architectures; 

[8]  ISO  861 3-1  : 1 991 ,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  1:Annex  F  -  A  Document  Application  Profile  Proforma  and 
Notation;  > 

[9]  ISO  861 3-7 :  (to  be  published).  Information  processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  interchange  Format  -  Part  7:  Amendment  -  Tiled  Raster  Graphics  Addendum 
to  ISO  8613,  Part  7; 

[10]  ISO  861 3-7 :  (to  be  published).  Information  processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  -  Part  7:  Amendment  -  Additional  Bit  Order  Mapping 
Addendum; 

[II]  ISO  646  :  1990,  Information  processing  -  ISO  7-bit  coded  character  sets  for  information 
interchange; 

[12]  ISO  8859-1  :  1983,  Information  processing  -  8-bit  Single-byte  coded  graphic  character  sets  -  Part 
1:  Latin  alphabet  No.  1; 

[13]     ISO  6937-2  : 1 983,  Information  processing  -  Coded  character  sets  for  text  communication  -  Part  2: 
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Latin  alphabet  and  non-alphabetic  characters; 

[14]     ISO  2022  :  1986,  Information  processing  -  ISO  7-bit  and  6-bit  coded  character  sets  -  Code 
extension  techniques; 

[15]     ISO  7350  :  1984,  Text  communication  •  Registration  of  graphic  character  subrepertolres; 

[16]     ISO  8824  :  1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Abstract  Syntax  Notation  One  (ASN.  1)  ; 

[17]     ISO  8825  : 1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  f-ASA/.  1); 

[18]     ISO  8879  : 1986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML)  ; 

[19]     ISO  8879  : 1 986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML),  Amendment  1; 

[20]     ISO  9069  :  1988,  Information  processing  -  SGML  support  facilities  -  SGML  Document  Interchange 
Format  (SDIF). 


[19]     Recommendation  T.4  :  1988.  Standardization  of  Group  3  Facsimile  Apparatus  for  Document 
Transmission. 

[20]     Recommendation  T.6 : 1988,  Facsimile  Coding  Schemes  and  Coding  Control  Functions  for  Group 
4  Facsimile  Apparatus. 

3    Definitions  and  terminology 
3.1  Definitions 

The  definitions  given  In  ISO  8613-1  are  applicable  to  this  document. 


2.2 


CCITT 
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3.2      Constituent  names 

Each  constituent  that  may  be  included  in  a  document  that  conforms  to  this  profile  has  been  given  a  unique 
name  which  serves  to  identify  that  constituent  throughout  this  profile. 

The  convention  is  that  full  names  are  used  (i.e.,  no  abbreviations  are  used),  two  or  more  words  in  a  name 
are  concatenated  and  each  word  begins  with  a  capital.  Examples  of  constituent  names  used  in  this  profile 
are  CompositePage,  DocumentLayoutRoot,  and  SpeclficBlock. 

In  clause  6,  each  constituent  provided  by  this  profile  is  underlined  once  at  the  point  in  the  text  at  which  the 
purpose  of  that  constituent  is  defined.  This  also  serves  to  identify  all  the  constituents  provided  by  this 
profile. 

The  same  constituent  names  are  also  used  in  the  technical  specification  in  clause  7  so  that  there  is  a 
one-to-one  correspondence  between  the  use  of  these  names  in  clauses  6  and  7. 

Although  the  constituent  names  relate  to  the  purpose  of  the  constituents,  the  sennantics  of  constituents  must 
not  be  implied  from  the  actual  names  that  are  used.  Also,  these  names  do  not  appear  in  an  interchanged 
document  but  a  mechanism  for  identifying  constituents  in  an  interchange  document  is  provided.  Thus  in 
an  application  using  this  profile,  the  constituents  may  be  known  to  the  user  by  different  names. 


4     Relationship  to  other  DAPs 

Functionally,  this  DAP  is  a  functional  superset  of  the  CCITT  Recommendation  T.503,  A  Document  Application 
Profile  for  the  Interchange  of  Group  4  Facsimile  Documents. 


5  Conformance 

In  order  to  conform  to  this  DAP,  a  data  stream  representing  a  document  must  meet  the  requirements 
specified  in  5.1. 

The  requirements  for  implementations  that  originate  and/or  receive  data  streams  conforming  to  this  DAP 
are  specified  in  5.2. 


5.1      Data  stream  conformance 

The  following  requirements  apply  to  the  encoding  of  data  streams  that  conform  to  these  agreements: 

a)  The  data  stream  shall  be  encoded  in  accordance  with  the  ASN.1  encoding  rules  defined  in 
ISO  8825  or  the  SGML  grammar  and  syntax  of  ISO  8879; 

b)  The  data  stream  shall  be  structured  in  accordance  with  the  interchange  format  defined  in 
clause  8; 

c)  The  document  shall  be  structured  in  accordance  with  only  the  formatted  document 
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architecture  class  specified  In  clause  7.  In  addition,  the  dcx^ument  shall  contain  all  nr«ndatory 
constituents  specified  for  that  class  and  may  optionally  contain  constituents  pennltted  for  that 
class  as  specified  in  clause  7; 

d)  Each  constituent  shall  contain  all  those  attributes  specified  as  required  for  that  constituent  in 
this  profile.  Other  attributes  may  be  specified  provided  they  are  permitted  for  that  constituent; 

e)  The  attributes  shall  have  values  within  the  range  of  pennisslble  values  specified  in  this  profile; 

f)  The  encoded  document  shall  be  structured  in  accordance  with  the  abstract  document 
architecture  defined  in  ISO  8613-2; 

g)  The  encoded  document  shall  be  structured  in  accordance  with  the  characteristics  defined  in 
clause  6  arxi  sliail  contain  only  those  features  defined  in  clause  6. 


5.2      Implementation  conformance 

This  clause  states  the  requirements  for  implementations  claiming  conformance  to  this  DAP. 

A  conforming  receiving  Implementation  must  be  capable  of  receiving  either  any  data  streams  confomning 
to  this  profile  structured  in  accordance  with  ODIF  or  any  data  streams  conforming  to  this  profile  structured 
in  accordance  with  ODL  or  both  of  these.  Receiving  usually,  but  not  always,  involves  recognizing  and 
further  processing  the  data  stream  elements. 


6    Characteristics  supported  by  this  DAP 

This  clause  describes  the  characteristics  of  documents  that  can  be  represented  by  data  streams  conforming 
to  this  profile.  This  clause  also  describes  how  these  characteristics  are  represented  in  terms  of  divisional 
components  of  the  data  streams. 

6.1  Overview 

This  DAP  describes  the  features  of  ISO  8613  that  are  needed  to  support  the  Interchange  of  documents 
containing  images,  it  specifies  interchange  formats  for  the  transfer  of  structured  documents  with  simple 
layout  structures. 

This  DAP  describes  documents  that  can  be  interchanged  in  the  formatted  form,  which  facilitates  the 
reproduction  of  a  document  as  intended  by  the  originator. 

The  content  within  the  document  forming  the  original  or  base  image(s)  may  be  formatted  processaWe  raster 
graphics,  formatted  processabie  geometric  graphics,  and/or  formatted  character.  This  is  intended  to 
facilitate  the  reproduction  of  the  document  content  as  intended  by  the  originator  or  allows  the  refomnatting 
of  the  document  content. 
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The  content  allowed  within  the  docunient  to  annotate  revisions  to  the  base  lmage(s)  may  also  be  fonnatted 
processabie  raster  graphics,  formatted  processabie  geometric  graphics,  and/or  formatted  character. 

This  clause  describes  the  layout  features  that  can  be  represented  in  documents  conforming  to  this  DAP. 
The  features  are  described  in  terms  that  are  typical  of  the  user-perceived  capabilities  and  semantics  found 
in  a  raster  document  interchange  environment. 

For  the  purpose  of  interchange,  a  document  is  represented  as  a  collection  of  constituents,  each  of  which 
is  represented  by  a  set  of  attributes.  The  constituents  that  make  up  a  formatted  document  are  defined 
beicw  in  this  clause  and  are  illustrated  in  figure  1. 

______________________ 

Document  Profil® 


Generic  Layout 
Structure  (Optional) 


Presentation  Style 
(Optional) 


Specific  Layout 
Structure 


Content  Portion 
Description 

Figure  1  -  Constituents 

(Constituents  defined  as  required  must  occur  in  any  document  that  conforms  to  this  profile.  Constituents 
listed  as  optional  may  or  may  not  be  present  in  the  document,  depending  on  the  requirements  erf  the 

particular  document. 

The  required  constituents  include: 

a)  a  document  profile; 

b)  layout  object  descriptions  representing  a  specific  layout  structure; 

c)  content  portion  description. 

The  only  optional  constituents  are  presentation  style  and  generic  layout  structure. 
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6.3      Layout  constituents 

This  clause  describes  the  features  of  the  layout  ot)jects  that  can  t>e  represented  In  documents  conforming 
to  this  DAP. 


6.3.1       Overview  of  the  layout  characteristics 

The  document  structure  allows  the  document  content  to  be  laid  out  and  presented  in  one  or  more  pages. 
Each  page  in  a  document  may  consist  of  a  single  raster  graphics  content.  This  would  be  the  case  for  an 
original  image  of  an  engineering  drawing,  illustration,  or  other  raster  scanned  image.  Optionally,  each  page 
in  a  document  may  consist  of  an  original  image  which  contains  raster  graphics,  geometric  graphics,  arxi/or 
character  content,  with  additional  character,  raster  graphics  or  geometric  graphics  content,  representing  a 
set  of  revision  annotations  of  the  original  image. 

A  specific  layout  structure  of  the  document  conforming  to  this  application  profile  consists  of  a  four-level 
hierarchy  consisting  of  a  document  layout  root,  composite  pages,  frames,  and  blocks.  The  document  can 
consist  of  multiple  composite  pages  where  each  page  represents  a  single  image  including  any  revision 
annotations.  The  composite  pages  consist  of  frames  which  in  turn  contain  blocks  containing  the  content 
associated  with  the  base  image  and  the  revision  annotation. 

Figure  2  Is  an  illustration  of  the  features  of  the  document  layout  structure  supported  by  this  DAP. 


Document 
Layout 
Root 


Composite 
Pages ( s ) 


Original 
Image 
Frame 


I 


Revision 
Annotation 
Frame(s) 


I 


Specific 
Block(s) 


Specific 
Block 


Figure  2  -  Document  layout  structure 
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A  DocumefTtLayoutRcx)t  is  the  top  i@ve!  in  a  document  layout  staicture.  A  DocumentLayoutRoot  consists 
of  a  sequence  of  one  or  m©r@  ComposltePage  constituent  constraints. 


6.3.3       Page  characteristics 

Only  one  constituent  constraint  is  provided  to  present  pages  within  a  document. 

A  document  consists  of  a  sequence  of  one  or  more  composite  pages,  in  a  document's  composite  page, 
two  types  of  frames  are  used  to  position  content  Information  on  tiie  page.  One  frame  type  is  used  to 
position  the  content  representing  the  original  image  on  the  page.  Only  one  frame  of  this  type  is  allowed  per 
page,  but  it  may  contain  any  number  of  raster  graphics,  geometric  graphics,  or  character  content  portions. 
The  second  frame  type  is  used  to  position  a  ciiaracter,  raster  graphics  or  geometric  graphics  content 
representing  a  revision  annotation  on  the  page.  There  may  be  one  or  more  of  the  frames  containing  a 
revision  annotation. 

A  document  may  consist  of  multiple  pages  of  different  sizes.  Each  page  may  be  either  landscape  or  portrait 
orientation.  Both  orientations  are  permitted  in  the  document. 


6.3.3.1  CompositePage 

A  CompositePage  is  a  constituent  constraint  which  defines  a  composite-page  that  corresponds  to  the  page 
area  used  for  presenting  the  sequence  of  an  Origlnalln^ge  frame  and  zero  or  more  RevlslonAnnotation 
frames. 


6.3.3.2        Page  dimensions 

A  wide  variety  of  page  dimensions  are  supported  Including  large  format  raster  documents.  The  dimensions 
of  the  pages  may  be  specified  as  any  value,  in  BMU  measurement  units,  including  the  larger  sizes  produced 
from  foidout-size  Images  and  roll  paper.  These  sizes  apply  to  both  portrait  and  landscape  orientations.  The 
page  sizes  Include:  ISO  A0-A5,  ANSI  A-K,  Japanese  legal  and  letter,  foldouts  27.94  cm  (1 1  in.)  X  34.56  cm 
(14  in.)  and  27.94  cm  (11  in.)  X  43.18  cm  (17  in.),  and  27.94  cm  (11  In.)  roll  paper. 

Dimensions  equivalent  to  or  less  than  the  common  assured  reproduction  area  (CARA)  of  ISO  A4  and  North 
American  Letter  (NAL)  in  portrait  or  landscape  orientation  are  basic  values.  Larger  page  sizes  including 
those  produced  from  roll  paper  are  non-basic  and  their  use  must  be  Indicated  in  the  document  profile  (See 
table  2). 

The  default  dimensions  are  the  CARA  of  North  American  Letter  (A).  Any  default  page  dimensions  may  be 
specified  in  the  document  profile  subject  to  the  maximum  dimensions  defined  above  by  using  the  "page 
dimensions'  attribute.  The  "page  position"  attribute  may  be  used  to  specify  the  position  of  the  pel  array 
image  on  the  page.  Although  actual  page  dimensions  may  be  used  allowing  for  the  raster  content  to 
completely  fill  a  page  leaving  no  borders,  it  is  advised  that  the  assured  reproduction  area  (ARA)  listed  in 
table  1  be  used  wherever  feasible.  See  7.3  of  ISO  8613-2  for  general  rules  for  positioning  pages  on 
presentation  surfoces. 
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6.3.3.3        Nominal  page  sizes 

The  nominal  page  sizes  that  may  be  specified  are  listed  in  table  1.  In  addition,  11  inch  roll  paper  of  any 
length  is  supported.  These  may  be  specified  in  portrait  or  landscape  orientations.  All  values  of  nominal 
page  size  are  non-basic  and  hence  all  values  used  in  a  document  must  be  indicated  in  the  document  profile 
using  the  "medium  type"  attribute  (See  table  2). 

Any  of  the  nominal  page  sizes  defined  in  table  1 ,  subject  to  the  restriction  specified  above,  may  be  specified 
as  the  default  value  in  the  document  profile. 

Table  1  also  includes  the  recommended  ARA.  Information  loss  nr^y  occur  when  a  document  is  reproduced 
if  the  dimensions  of  the  CompositePage  exceed  the  ARA  for  the  specified  nominal  page  size. 


6.3.4  Originallmage 

An  Originallmage  is  a  constituent  constraint  which  defines  a  lowest  level  frame  used  for  laying  out  the 
original  image  of  an  engineering  drawing,  illustration  or  other  image.  This  frame  contains  one  or  more 
SpecificBiocks  each  of  which  may  contain  one  of  a  character  content  portion,  a  raste**  graphics  content 
portion,  or  a  geometric  graphics  content  portion.  Note  that  there  must  be  exactly  one  Origninallmage  frame 
on  each  page. 

This  type  of  frame  has  a  fixed  position  and  dimensions.  The  position,  if  not  specified,  defaults  to  the  origin 
of  the  page.  The  dimensions,  if  not  specified,  default  to  the  maximum  size  that  can  t>e  achieved  for  the 
positton  within  the  area  of  the  page. 


6.3.5  RevislonAnnotation 

A  RevislonAnnotation  is  a  constituent  constraint  which  defines  a  lowest  level  frame  used  for  laying  out  the 
revision  annotation  associated  with  the  original  image.  This  frame  contains  a  single  SpecificBlocl<  containing 
either  a  character  content  portion,  a  raster  graphics  content  portion  or  a  geometric  graphics  content  portion. 

This  type  of  frame  has  a  fixed  position  and  dimensions.  This  provision  provides  for  the  capability  of 
positioning  of  revision  annotation  anywhere  on  the  page.  Registration  of  revision  annotation  over  a  portion 
of  the  original  image,  as  in  revision  artwork,  is  accomplished  using  this  capability. 


6.3.6  SpecificBlock 

A  SpecificBiock  is  a  constituent  constraint  which  defines  a  basic  layout  object  used  to  position  and  image 
the  content  portions  associated  with  either  an  Originallmage  or  RevislonAnnotation  frame. 

The  position  of  the  b>lock  is  fixed  and  defaults  to  the  origin  of  the  superior  frame.  The  dimensions  default 
to  the  maximum  size  that  can  be  achieved  for  the  position  within  the  area  of  the  superior  frame. 
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6.3.7  GenerlcBlock 

GenfHicBlock  is  a  constituent  constraint  which  defines  a  layout  object  dass  which  can  define  content  that 
is  common  and  can  be  referenced  throughout  the  document.  Any  content  type  (raster,  character,  or 
geometric  graphics)  can  be  defined  using  this  technique. 
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Table  1  Dimenslont  for  various  page  sizes 


Pag«  typ* 

Size 

Size  (BMU) 

ARA  (BMU) 

•  Metric 

IS0-A5 

148mm  X  210mm 

7015  X  9920 

not  defined 

IS0-A4 

210mm  X  297mm 

9920  X  14030 

9240  X  13200 

IS0-A3 

297mm  x  420mm 

14030  X  19840 

13200  X  18480 

IS0-A2 

420mm  X  594mm 

19840  x  28060 

18898  x  27118 

IS0-A1 

594mm  x  841mm 

28060  x  39680 

26173  x  37843 

ISO-AO 

841mm  X  1189mm 

39680  x  56120 

37843  X  54283 

-  ANSI.  North  American  (NA) 

NAA 

8.5in  X  Ilin 

10200  X 13200 

9240  X  12400  1 

NA-B 

Ilin  X  17in 

13200  x  20400 

12744  X  19656 

NA-C 

17in  X  22in 

20400  x  26400 

19500  x  25800 

NA-D 

22in  X  34in 

26400  x  40800 

25800  x  39600 

NA-E 

34in  X  44in 

40800  x  52800 

39600  x  52200 

NA-F 

28in  X  40in 

33600  x  48000 

32400  X  47400 

NA-G 

Ilin  X  90in 

13200  X  108000 

12400  X  106800 

NA-H 

28in  X  143in 

33600  X  171600 

31400  X  170400 

NA-J 

34in  X  176in 

40800  x  211200 

39600  x  210000 

NA-K 

40in  X  143in 

48000  X 171600 

47400  X  170400 

NA-Legal 

8.5in  X  14in 

10200  X  16800 

9240  X  15480 

-  Foldouts 

Small 

Ilin  X  14in 

13200  X  16800 

12744  X  15480 

NA-B 

Ilin  X  17in 

13200  x  20400 

12744  X  19656 

-  Japan 

Legal 

257mm  x  384mm 

12141  X 17196 

11200x  15300  1 

Letter 

182mm  x  257mm 

8598  X 12141 

7600  X 10200  1 

Tutorial  Note  -  These  page  sizes  are  for  the  portrait  orientation. 


11 


PART  22  -  ODA  Image  DAP  December  1992  (Stable) 


Table  2  Layout  attributes 


Attributes 

Basic  values 

Default 
values 

Non-basic 
values 

Page  dimensions  ** 

CARA  NA  A. 
ISO  A4 

CARA  NA-A 

ARA  NA  B-K, 
ISO  A0-A3,Japan 
legal, 

11'  Roll  Paper 

Medium-type  ** 
(Nominal  page  size) 

None 

None 

NA  A-K, 
ISO  A0-A5, 
Japan  letter  & 
legal. 

11'  Roll  Paper 

Tutorial  Note  -  See  table  1 


6.4      Document  layout  characteristics 

This  DAP  provides  only  for  fornnatted  docunnents.  IHence,  no  provision  is  nr^de  for  constraining  the 
document  layout  process  other  than  as  Implied  in  the  formatted  documents  supported  by  this  DAP.  In 
particular,  these  formatted  documents  are  characterized  by  the  following: 

a)  Documents  containing  only  composite  pages; 

b)  Documents  may  contain  one  or  more  pages; 

c)  Pages  may  vary  by  orientation  within  a  document; 

d)  As  a  minimum,  each  page  contains  a  single  raster  graphics,  geometric  graphics,  or  character 
content  portion,  representing  the  original  image; 

e)  Each  page  may  additionally  contain  one  or  more  character,  raster  graphics  or  geometric 
graphics  content  portions  representing  revision  annotation; 

f)  Content  is  positioned  within  fixed  position  and  dimension  frames. 


6.5      Content  layout  and  imaging  control 

A  document  is  modelled  as  an  original  image  with  optional  revision  annotation(s).  The  original  image  and 
the  revision  annotation  (s)  may  be  represented  by  either  character,  raster  graphics,  or  geometric  graphics 
content  portions,  as  specified  in  ISO  8613-6,  ISO  8613-7  and  ISO  8613-8,  respectively. 

The  content  architectures  that  may  be  specified  using  the  attribute  "content  architecture  class"  are  formatted 
character,  formatted  processable  raster  graphics  and  formatted  processable  geometric  graphics.  Any  of 
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the  above  contents  may  be  specified  as  the  default  in  the  document  profile. 


6.5.1 


Raster  graphics  content 


6.5.1.1 


Introduction 


This  clause  defines  the  features  that  are  applicable  to  the  raster  graphics  content. 
The  default  values  for  the  following  features  may  be  specified  in  the  document  profile: 

a)  type  of  coding  (required); 

b)  compression; 

c)  pel  path; 

d)  line  progression; 

e)  pel  spacing; 

f)  spacing  ratio. 

The  specification  In  a  document  of  a  non-basic  value  by  a  presentation  or  coding  attribute  must  be  indicated 
In  the  document  profile. 


6.5.1.2        Raster  grapliics  content  architecture 

The  formatted  processable  raster  graphics  content  architecture  is  supported  by  this  DAP  and  will  frequently 
be  the  primary  content  architecture  in  a  document. 

In  a  composite  page,  multiple  content  portions  may  be  associated  with  the  original  image,  whereas  only  one 
content  portion  may  be  associated  with  a  given  revision  annotation. 


6.5.1.3        Raster  graphics  encoding  methods 

The  content  may  be  encoded  in  accordance  with  the  encoding  schemes  defined  in  CCITT 
Recommendations  T.4  and  T.6.  In  the  case  of  T.4,  either  the  one-dimensional  or  two  dimensional  encoding 
scheme  may  be  used.  Also  the  'bit-map  encoding'  scheme  defined  in  ISO  8613-7  may  be  used.  All  these 
forms  of  encoding  may  be  used  in  a  single  document  and  all  are  basic  values.  'Uncompressed'  mode  of 
encoding  may  also  be  used  but  only  as  a  non-basic  value. 

In  a  content  portion,  it  is  required  that  the  coding  attribute  "number  of  pels  per  line"  is  specified.  The  coding 
attribute  "number  of  lines"  may  also  be  specified.  No  restriction  is  placed  on  the  values  that  may  be 
specified  for  these  coding  attributes.  This  profile  places  no  constraints  on  the  size  of  the  pel  arrays  that  may 
be  used. 
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The  type  of  coding  method  used  is  specified  by  the  attribute  "type  of  coding".  The  use  of  this  attribute  is 
mandatory  in  the  'document  architecture  defaults"  of  the  document  profile  to  define  the  default  value  of 
either  T.6  encoding'  (untiled),  T.6  encoding  -  MSB'  (untiled),  or  'tiled  encoding'.  The  use  of  this  attribute 
in  the  description  erf  the  content  portions  is  non-mandatory.  If  this  attribute  is  not  specified  for  a  particular 
content  portion,  then  the  default  value  specified  In  the  "document  architecture  defaults"  of  the  document 
profile  is  used. 

If  the  tiled  encoding  method  is  used,  the  deteult  value  of  512  for  the  "number  of  pels  per  tile  line"  and 
"number  of  lines  per  tile"  must  be  used.  No  other  values  are  supported,  therefore  these  two  attributes  do 
not  need  to  be  specified.  If  the  "tile  types"  attribute  is  not  present,  then  all  tiles  will  be  T.6  encoded.  If  It  Is 
present,  then  there  must  be  a  value  specified  for  each  tile  in  which  case  only  'null  background',  'null 
foreground',  'T.6  encoded',  'T.6  encoded  -  MSB',  or  'bitmap  encoded'  values  are  supported.  The  T.4 
encodings  are  not  supported.  There  are  no  restrictions  on  the  use  of  the  tiling  offset"  attribute  other  than 
that  specified  In  ISO  8613-7  Addendum. 

See  table  D.I,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  t>asic,  default,  and  non-basic  values. 


6.5.1.4        Raster  presentation 

Raster  presentation  is  controlled  by  the  presentation  attributes  specified  in  ISO  8613-7.  This  DAP  provides 
for  additional  constraints  on  these  presentation  attributes  as  specified  below. 

The  basic  values  for  the  attribute  "pel  path"  supported  by  this  profile  are  0  and  90  degrees.  The  "pel  path" 
values  of  180  and  270  degrees  are  non-basic. 

The  t>asic  values  for  the  attribute  "line  progression"  supported  by  this  profile  is  270  degrees.  The  "line 
progression"  value  of  90  degrees  is  non-basic. 

Any  value  may  be  explicitly  specified  for  pel  spacing  provided  that  the  spacing  t>etween  pels  is  not  less  than 
1  BMU.  The  pel  spacing  need  not  be  an  integer  value.  The  value  of  'null'  may  not  t^e  specified  because 
the  scalable  layout  process  is  not  supported.  The  specification  of  the  spacings  of  16, 12,  8,  6,  5,  4.  3.  2, 
and  1  BMU  between  adjacent  pels  are  basic.  The  specification  of  any  other  spacing  is  non-basic  and  must 
be  specified  In  the  document  profile. 

NOTES 

1  The  basic  pel  spacing  values  listed  above  are  equivalent  to  resolutions  of  75, 100, 150,  200,  240,  300. 400, 
600,  and  1200  pels  per  25.4mm  respectively  when  the  BMU  is  interpreted  as  1/1200  inch. 

2  The  attribute  'pel  spacing*  specifies  two  integers,  the  ratio  of  which  determines  the  pel  spacing.  No 
restriction  is  placed  on  the  values  of  these  integers. 

There  are  no  restrictions  on  the  use  of  the  "clipping"  attribute.  The  "image  dimensions"  attribute  is  not 
supported. 

There  are  no  restrictions  placed  on  the  value  of  the  "spacing  ratio"  attribute  providing  that  the  resultant  line 
spacing  is  not  less  than  1  BMU.  Also,  the  line  spacing  need  not  be  an  integral  number  of  BMUs.  All  values 
are  basic. 
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See  table  D.2,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-basic  values. 


6.5.2       Character  content 

The  fomiatted  character  content  is  permitted  in  this  DAP  for  use  In  either  the  original  Image  or  in  revision 
annotations  of  that  original  Image. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation  attribute  or  control  function  must 
be  indicated  in  the  document  profile. 


6.5.2.1        Character  content  architecture  class 

When  using  character  content,  only  one  content  portion  may  be  associated  with  a  basic  component.  The 
content  information  in  a  content  portion  must  be  present. 


6.5.2.2        Character  repertoires 

The  basic  character  set  supported  by  this  profile  is  the  primary  character  set  of  ISO  8859-1 .  This  must  be 
designated  to  the  GO  set  and  invoked  to  the  GL  Any  other  graphic  character  set  which  is  registered  in 
accordance  with  ISO  2375  may  be  designated  and  invoked  at  any  point  in  the  document  provkled  its  use 
is  announced  in  the  document  profile  as  a  non-t>aslc  value  using  the  character  presentation  attribute 
"graphic  character  sets'.  No  locking  shift  functions  are  specified  In  this  presentation  attribute.  The  default 
graphic  character  sets  which  apply  to  the  content  portions  within  a  document  can  be  specified  in  the 
document  profile  using  the  presentation  attribute  "graphic  character  sets". 

Using  code  extension  techniques,  the  graphic  character  sets  designated  and /or  invoked  at  the  beginning 
of  a  content  portion  containing  character  content  are  specified  using  the  presentation  attribute  "graphics 
character  sets". 

If  the  character  set  defined  In  ISO  6937-2  is  designated  and  Invoked,  then  the  use  of  any  sub-repertoire 
registered  according  to  ISO  7350  may  be  specified.  All  sub-repertoires  are  non-basic  and  their  use  must 
be  indicated  in  the  document  profile. 


6.5.2.3        Code  extension  techniques 

The  code  extension  techniques  specified  in  ISO  2022  may  be  used  subject  to  the  following  restrictions: 

a)  GO  set:  only  the  primary  character  sets  of  ISO  6937-2,  ISO  8859-X  (where  ISO  8859-X 
con'esponds  to  any  finalized  part  of  ISO  8859)  and  a  version  of  ISO  646  may  be  designated  for 
this  set;  these  character  sets  may  only  be  invoked  in  GL; 

b)  G1,  G2,  G3  sets:  no  restrictions  are  placed  on  the  character  sets  that  may  be  designated  for 
these  sets;  these  sets  may  only  be  invoked  in  GR; 

c)  The  locking  and  single  shift  functions  allowed  should  be  restricted  to  the  following: 
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LS1R  for  the  G1  set 
LS2R  for  the  G2  set 
LS3R  for  the  G3  set 
SS2 
SS3; 

d)  When  specifying  the  presentation  attribute  "graphic  character  sets",  it  is  necessary  to  invoke 
character  sets  for  both  GL  and  GR.  Thus  an  allowed  character  set  must  be  designated  into  GO, 
as  specified  above,  and  invoked  into  GR.  it  is  also  necessary  to  invoke  a  character  set  into  GR 
which  has  been  designated  into  G1,  G2  or  G3  sets; 

e)  The  empty  set  should  be  designated  and  invoked  in  GR  if  no  other  specific  set  is  invoked 
intoGR. 

The  announcement  and  encoding  of  these  functions  are  to  be  as  specified  in  ISO  2022. 


6.5.2.4        Line  spacing 

Any  value  of  line  spacing  may  be  specified.  Values  of  150,  200,  300  and  400  BMUs  are  basic;  the  use  of 
any  other  value  in  a  document  is  non-basic  and  must  be  indicated  in  the  document  profile.  The  line  spacing 
may  be  specified  at  the  beginning  of  the  content  associated  with  a  t)asic  component  using  the  presentation 
attribute  "line  spacing".  The  value  may  be  changed  anywhere  within  the  content  portion  using  the  control 
functions  SVS  and  SLS. 


6.5.2.5        Character  spacing 

Any  value  of  character  spacing  may  be  specified.  Values  greater  than  or  equal  to  100  are  basic;  the  use 
of  any  other  value  in  a  document  is  non-basic  and  must  be  indicated  in  the  document  profile.  The  character 
spacing  may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic  component  using  the 
attribute  "character  spacing".  The  value  may  be  changed  anywhere  within  a  content  portion  using  the 
control  functions  SHS  or  SCS. 


6.5.2.6        Character  path  and  line  progression 

Both  horizontal  and  vertical  writing  directions  may  be  used  within  a  character  content.  In  the  case  of 
horizontal  writing,  the  characters  progress  either  from  left  to  right  or  from  right  to  left  across  the  page  and 
the  line  progression  is  from  the  top  of  the  page  to  the  bottom.  In  the  case  of  vertical  writing,  the  characters 
progress  from  the  top  of  the  page  to  the  bottom  and  the  line  progression  is  from  the  right  to  the  left.  The 
values  of  character  path  and  line  progression  may  be  specified  at  the  beginning  of  the  content  associated 
with  a  basic  component  using  the  presentation  attributes  "character  path"  and  "line  progression". 
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respectively.  These  values  cannot  be  changed  within  a  content  portion. 


6.5.2.7        Character  orientation 

The  character  orientation  may  be  specified  as  0  or  90  degrees  depending  on  whether  vertical  or  horizontal 
writing  Is  used.  When  vertical  writing  Is  used,  characters  are  normally  orientated  at  0  degrees.  When 
horizontal  writing  is  used,  characters  may  be  orientated  at  0  or  90  degrees.  A  value  of  0  degrees  Is  basic; 
a  value  of  90  degrees  is  non-basic  and  Its  use  in  a  document  must  be  Indicated  In  the  document  profile. 
The  value  of  the  character  orientation  is  specified  at  the  beginning  of  the  content  associated  with  a  basic 
component  by  the  presentation  attribute  "character  orientation".  This  value  cannot  be  changed  within  the 
content. 


6.5.2.8  Emphasis 

The  following  modes  of  emphasising  graphic  characters  may  be  distinguished: 


a) 

normal  rendition; 

b) 

normal  Intensity; 

c) 

increased  intensity  (bold); 

d) 

Italicised; 

e) 

not  italicised; 

f) 

underiined; 

g) 

doubly  underiined; 

h) 

not  underiined; 

1) 

crossed-out; 

J) 

not  crossed-out. 

All  the  above  modes  of  emphasis  are  t>aslc.  If  no  default  mode  Is  explicitly  specified  In  the  document  profile, 
then  the  default  mode  Is  nomnal  rendition.  The  mode  of  emphasis  may  be  specified  at  the  beginning  of  the 
content  associated  with  a  basic  component  using  the  presentation  attribute  "graphic  rendition".  The  mode 
may  be  changed  anywhere  within  the  content  using  the  control  function  SGR.  The  mode  of  emphasis 
remains  In  effect  within  the  content  associated  with  a  basic  component  until  changed  into  a  mutually 
exclusive  mode  or  by  the  specification  of  'normal  rendition'.  Mutually  exclusive  modes  are  normal/Increased 
Intensity,  Italicized/not  Italicized,  underiined/not  underiined  and  crossed  out/not  crossed-out.  One  mode 
from  each  mutually  exclusive  set  may  be  In  operation  at  any  point  In  the  document  content.  Normal 
rendition  cancels  the  effect  of  all  methods  of  emphasis  that  are  cun-ently  in  operation  and  specifies  that  the 
text  should  be  displayed  in  accordance  with  the  default  rendition  parameters  set  for  the  presentation  device. 
Thus,  for  example,  If  it  is  required  to  ensure  that  the  content  Is  not  underlined,  then  it  is  necessary  to 
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explicitly  specify  that  underlined  is  not  to  be  used. 


6.5.2.9  Tabulation 

Tabulation  stop  positions  may  be  specified  at  any  character  position  along  the  character  path.  Each  stop 
Is  specified  by  means  of  the  foiiowing: 

a)  The  tabulation  position  relative  to  the  margin  position  in  the  direction  opposite  to  the 
character  path; 

b)  An  alignment  qualifier  tfiat  specifies  the  type  of  alignment  to  be  used  at  the  designated 
tabulation  position.  The  type  may  be  specified  as  one  of  the  following: 

start  aligned: 

.  ..    end  aligned; 

centered; 

aligned  around. 

These  alignment  qualifiers  are  defined  in  ISO  8613-6.  If  the  alignment  qualifier  is  not  explicitly  specified,  then 
It  is  assumed  that  start  aligned  is  to  be  used.  Only  one  set  of  tabulation  stops  can  be  specified  to  be 
applicable  to  the  content  associated  with  a  basic  component.  No  limit  is  placed  on  the  number  of  tabulation 
stops  that  can  be  specified  within  a  given  set.  The  set  of  tat>ulation  stop  positions  associated  with  tfie 
content  of  a  basic  component  are  specified  using  the  presentation  attribute  "line  layout  tat)le'.  Tabulation 
stop  positions  are  invoked  within  the  content  using  the  control  function  STAB. 


6.5.2.10  Alignment 

This  feature  is  concerned  with  how  the  first  and  last  characters  on  each  line  of  cliaracter  content  is  to  be 
laid  out  during  the  formatting  process.  The  foiiowing  values  of  alignment  may  be  specified: 

a)  start  aligned; 

b)  end  aligned; 

c)  centred; 

d)  Justified. 

The  semantics  of  these  values  are  as  defined  in  ISO  8613-6.  The  presentation  attribute  "alignment"  Is  used 
to  specify  the  alignment  that  is  applicable  to  the  content  associate  with  a  basic  component.  The  alignment 
value  cannot  be  changed  within  a  content  portion. 
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6.5.2.11  Fonts 

Any  number  of  fonts  niay  used  within  a  document.  The  fonts  used  in  a  particular  document  are  specified 
in  the  document  profile  using  the  attribute  "font  iisf .  Further  information  concerning  the  specification  of  font 
references  in  the  document  profile  is  given  in  Annex  B.  The  fonts  that  may  be  used  within  the  content 
associated  with  each  basic  component  are  specified  by  the  presentation  attribute  'character  fonts'.  Up  to 
10  fonts  tal<en  from  the  list  specified  by  the  attribute  font  iisf  may  be  specified  by  the  attribute  'character 
fonts".  The  font  to  t>e  used  at  the  start  of  the  content  associated  with  a  basic  comporient  is  specified  using 
the  attribute  "graphic  rendition".  The  fonts  used  within  the  content  may  t>e  changed  using  the  control 
functton  SGR. 


6.5.2.12       Reverse  character  strings 

Bi-directional  writing  is  supported  by  this  profile.  Hence,  a  string  of  characters  in  a  content  portion 
associated  with  a  basic  component  may  be  specified  to  t>e  imaged  in  the  reverse  direction  of  the 
immediately  preceding  character  string.  Such  strings  can  be  specified  by  the  control  function  SRS  as 
defined  in  ISO  8613-6.  This  control  function  is  provided  for  cases  in  which  the  text  t)elongs  to  different 
languages  and  the  character  content  is  written,  for  example,  from  left  to  right  or  from  right  to  left  within  the 
same  line  of  characters,  dependent  upon  the  language  and/or  character  set  being  used. 

NOTE  -  The  use  of  this  control  function  cannot  be  indicated  in  the  docunnent  profile.  Thus  it  is  intended  that 
implementations  should  ignore  this  control  function  when  reverse  character  string  layout  and  presentation  is 
not  supported. 


6.5.2.13      Superscripts  and  subscripts 

I    Superscripts  and  subscripts  may  be  specified  anywhere  within  the  content  associated  with  a  basic 
I    component  by  using  the  control  functions  'PLU'  and  'PLD'.  The  use  of  these  control  functions  shall  be  in 
accordance  with  ISO  8613-6. 


The  control  function  'SUB'  is  provided  to  represent  characters  produced  by  a  local  system  that  cannot  be 
I   represented  by  a  character  within  a  character  set  supported  by  this  profile. 

6.5.2.15       Use  of  control  functions 

j  The  following  is  a  list  of  all  the  control  functions  and  parameter  values  (where  applicable)  that  may  be 
I   specified  in  character  content: 

I  a)  SIHS  -  set  horizontal  spacing; 

I  b)  SOS  -  set  character  spacing; 

c)  SVS  -  set  vertical  spacing; 


6.5.2.14 


Substitution  of  characters 
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d)  SLS  -  set  line  spacing; 

e)  SGR  -  set  graphic  rendition; 

f)  STAB  -  selective  tabulation  (allowed  parameter  values:  any); 

g)  SRS  -  start  reverse  string  (allowed  parameters:  any); 

h)  PLD  -  partial  line  down; 

i)  PLU  -  partial  line  up; 

j)  SUB  -  substitute  character; 
k)  SP  -  space; 
I)  CR  -  carriage  retum; 
m)  l-F  -  line  feed; 

n)     -  code  extension  control  functions  . 
6.5.3       Geometric  graphics  content 

The  formatted  processable  graphics  content  is  permitted  in  this  DAP  for  use  in  either  the  original  image  or 
in  the  revision  annotation  of  that  image.  Such  geometric  graphics  content  is  encoded  as  CGM  (Computer 
Graphics  Metafile)  metafiles  in  accordance  with  ISO  8632  and  ISO  8613-8.  Each  CGM  figure  must  consist 
of  a  single  picture  only. 

Further  information  concerning  the  specification  of  geometric  graphics  content  information  is  given  in  Annex 
B. 

6.6      Miscellaneous  features 
6.6.1       Resource  documents 

A  GenericBlock  may  refer  to  a  corresponding  constituent  in  a  resource  document.  The  GenericBlock  in  the 
resource  document  may  refer  to  content  portions  and  to  presentation  styles  that  are  contained  within  the 
resource  document.  These  are  the  only  constituents  that  may  appear  in  a  resource  document. 
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6.6.2       Application  comments 

Specification  of  tlie  attribute  'application  comments"  is  optional.  Wlien  used  in  conjunction  with  the  type 
of  coding'  of  tiled  encoding',  it  contains  a  sequence  of  positive  integers,  one  for  each  tHe  in  the  content 
portion.  The  sequence  of  integers  is  a  set  of  indices  representing  the  octet  offsets  to  the  l)eginning  of  the 
respective  tHes.  starting  from  the  beginning  of  the  'content  information'.  A  tUe  Index  of  zero(0)  indicates  that 
the  respective  tie  is  null.  The  integers  will  be  sequenced  In  the  same  order  as  the  tiles.  The  tHes  wHI  be 
sequenced  primarily  in  the  pel  path  and  secorKlarily  in  the  line  progression  direction  as  defined  by  the 
presentation  attributes. 


6.7      Document  management  features 

Every  document  interchanged  in  accordance  with  this  DAP  must  include  a  document  profile  containing 
informatton  which  relates  to  the  document  as  a  whole. 

The  features  specified  by  the  document  profile  are  listed  below.  A  definition  of  the  infonnation  contained 
in  these  features  is  given  in  the  corresponding  attribute  definitions  in  ISO  8613-4. 


Document 

constituent  Information: 

a) 

specific  layout  structure; 

b) 

generic  layout  structure; 

c) 

presentation  styles  (optional); 

d) 

resource  document  information  (optional). 

Document 

characteristics: 

a) 

document  application  profile; 

b) 

document  application  profile  defaults; 

c) 

document  architecture  class; 

d) 

content  architecture  class; 

e) 

interchange  format  class; 

f) 

ODA  version  date; 

g) 

raster  graphics  content  defaults. 

Non-basic 

document  characteristics: 

a) 

page  dimensions; 

1 
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b)  medium  type; 

c)  raster  graphics  presentation  features. 
Document  management  attributes: 

a)  document  description  (see  note  1); 

b)  dates  and  times; 

c)  originators; 

d)  otiier  user  information; 

e)  external  references; 

f)  ioc£d  file  references; 

g)  content  attributes; 

h)  security  Information. 

NOTE  -  The  document  description  includes  the  specification  of  the  document  reference. 
The  attributes  applicable  to  the  document  profile  are  defined  in  table  D.3,  Annex  D. 

7    Specification  of  constituent  constraints 
7.1      Document  profile  constraints 

7.1.1       Macro  definitions 

-  General  macros  - 
DEFINE(FDA,  "{'formatted'}") 

DEFINE(DAC,"DocumentProfile  (Document-archltecture-class)") 

DEFINE(FC."  ASN.1{2  8  2  60}")  -  Character  formatted  ~ 

DEFINE(FPR.'  ASN.1  {2827  2}')  ~  Raster  graphics  formatted  processable  ~ 
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DEFINE(FPG,"  ASN.1  {2  8  2  8  0}")   -  Geometric  graphics  formatted  processaUe  - 

~  Basic  page  dimensions.  - 
DEFINE(BasicPageDimension,'' 

REQ  #horl2ontal-dlmension  {REQ  #fixed-dlmension  {  1..9240  }}. 
REQ  #vertlcal-dlmension  {REQ  #flxed-dimension  {  1.. 12400  }} 
I  REQ  #horizontal-dimension  {REQ  #fixed-dimenslon  {  1.. 12400  }}, 
REQ  #vertlcal-dlmension  {REQ  #fixed-dimenslon  {  1..9240  }} 
") 

-  Any  size  equal  to  or  smaller  than  CARA  (Common  Assured  Reproduction  Area)  of  ISO  A4  and  MA  A.  Both 
Portrait  and  Landscape  n^y  be  specified.  - 

~  Non-basic  page  dimensions.  - 
DEFINECNonBaslcPageDimensions," 

{REQ  #horl2ontal-dimenslon  {REQ  #fixed-dlmension  {1.. 39680}}, 

REQ  #vertical-dlmension  {REQ  #fixed-dimension  {12401..56120}}} 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dlmension  {9241. .39680}}, 

REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 56120}}} 

-  up  to  ISO  AO  portrait  - 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimenslon  {1.. 56120}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {9241. .39680}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dlmension  {12401..56120}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimenslon  {1.. 39680}}} 

-  up  to  ISO  AO  landscape  - 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {12401..211200}}} 
!  (REQ  #hofizontal<i(mension  {REQ  #fixed-dlmension  {9241. .48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimenslon  {1.. 211200}}} 

-  up  to  ANSI  J/K  portrait 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 21 1200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {9241. .48000}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {12401..211200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 48000}}} 

--  up  to  ANSI  J/K  landscape  - 
I  {REQ  #hori2ontal-dimension  {REQ  #fixed-dimension  {1..12141}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {12401..17196}}} 
I  {REQ  #hori2ontal-dimension  {REQ  #fixed-dimension  {9241. .12141}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 17196}}} 

-  up  to  Japanese  legal  portrait  -- 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 17196}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {9241..12141}}} 
I  {REQ  #hori2ontal-dlmension  {REQ  #fixed-dimension  {12401..17196}}. 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 12141}}} 

-  up  to  Japanese  legal  landscape  - 

I  {REQ  #hori2ontal-dimension  {REQ  #fixed-dimension  {13200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {>=  16801}}} 
~  Any  portrait  size  larger  than  the  typical  foldout  size  (11  in  x  14  in)  including  11  inch  roll  paper.  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {>=  16801}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {13200}}} 
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-  Any  landscape  size  larger  than  the  typical  foldout  size  (14  in  x  1 1  in)  including  1 1  inch  roll  paper  ~ 
") 

DEFINE(PermissiblePageDimensions," 

{REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 39680}}, 
REQ  #vertlcal-dimension  {REQ  #fixed-dimenslon  {1.. 56120}}} 

-  up  to  ISO  AO  portrait  - 

I  {REQ  #horizontal-dimenslon  {REQ  #fixed-dimension  {1..56120}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 39680}}} 

--  up  to  ISO  AO  landscape  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1..48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1..211200}}} 

-  up  to  ANSI  J/K  portrait  - 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dlmension  {1..211200}}, 
REQ  #vertlcal-dimenslon  {REQ  #fixed-dimension  {1.. 48000}}} 

-  up  to  ANSI  J/K  landscape  -- 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 12141}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 17196}}} 

-  up  to  Japanese  legal  portrait  - 

I  {REQ  #horizontal-dimenslon  {REQ  #fixed-dimension  {1.. 17196}}, 
REQ  #vertical-dimension  {REQ  #flxed-dimension  {1.. 12141}}} 
~  up  to  Japanese  legal  landscape  ~ 

")• 

DEFINE(NominalPageSizes,* 

-  ISO  Page  Sizes  - 

REQ  #horizontal-dimension  {7015},  REQ  #vertical-dimension  {9926} 

--  ISO  A5  Portrait  -- 
I  REQ  #horizontal-dimension  {9920},  REQ  #vertical-dimension  {7015} 

--  ISO  A5  Landscape  - 
I  REQ  #horizontal-dimension  {9920},  REQ  #vertical-dimension  {14030} 

--  ISO  A4  Portrait  -- 
I  REQ  #horizontal-dimension  {14030},  REQ  #vertical-dimension  {9920} 

-  ISO  A4  Landscape -- 

I  REQ  #horizontal-dimension  {14030},  REQ  #vertical-dimension  {19840} 

-  ISO  A3  Portrait  - 

I  REQ  #horizontal-dimension  {19840},  REQ  #vertical-dimenslon  {14030} 

-  ISO  A3  Landscape  - 

I  REQ  #horlzontal-dimension  {19840},  REQ  #vertical-dimenslon  {28060} 

-  ISO  A2  Portrait 

I  REQ  #horizontal-dimension  {28060},  REQ  #vertical-dimension  {19840} 

-  ISO  A2  Landscape  - 

I  REQ  #horlzontal-dimension  {28060},  REQ  #vertical-dimension  {39680} 

-  ISO  A1  Portrait 

I  REQ  #horizontal-dimension  {39680},  REQ  #yertical-dimension  {28060} 

-  IS0A1  Landscape - 

I  REQ  #horlzontal-dimension  {39680},  REQ  #vertical-dimension  {56120} 

-  ISO  AO  Portrait 
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I  REQ  #horl2ontal-dimenslon  {56120},  REQ  #vertlcal-dlmenslon  {39680} 

-  ISO  AO  Landscape  - 

-  ANSI  Page  Sizes  ~ 

I  REQ  #hori2ontal-dimenslon  {10200},  REQ  #vertlcal-dimenslon  {13200} 

-  ANSI  A  Portrait - 

I  REQ  #horizontal-dlmenslon  {13200},  REQ  #vertlcal-dimenslon  {10200} 

-  ANSI  A  LarxJscape  - 

I  REQ  #horizontal-dimension  {10200},  REQ  #vertical-dimension  {16800} 

-  ANSI  Legal  Portrait  - 

I  REQ  #horlzontal-dimenslon  {16800},  REQ  #venical-dimension  {10200} 

~  ANSI  Legal  LarxJscape  - 
I  REQ  #hoiizontal-dimenslon  {13200},  REQ  #vertical-dimension  {20400} 

~  ANSI  B  Portrait 

I  REQ  #horizontal-dimension  {20400},  REQ  #vertlcal-dimenslon  {13200} 

--  ANSI  B  Landscape  - 
I  REQ  #horlzontal-dimension  {20400},  REQ  #vertical-dimension  {26400} 

-  ANSI  C  Portrait  - 

I  REQ  #horizontal-dimenslon  {26400},  REQ  #vertical-dimenslon  {20400} 

-  ANSI  C  Landscape  - 

I  REQ  #horizontal-dimension  {26400},  REQ  #vertical-dimension  {40800} 

-  ANSI  D  Portrait  - 

I  REQ  #horizontal-dimenslon  {40800},  REQ  #vertical-dimension  {26400} 

-  ANSI  D  Landscape  - 

I  REQ  #horizontal-dimension  {40800},  REQ  #vertical-dimension  {52800} 

-  ANSI  E  Portrait  ~ 

I  REQ  #horlzontal-dimension  {52800},  REQ  #vertical-dimenslon  {40800} 

--  ANSI  E  Landscape  - 
I  REQ  #horizontal-dimension  {33600},  REQ  #vertical-dimenslon  {48000} 

-  ANSI  F  Portrait  ~ 

I  REQ  #horizontal-dimension  {48000},  REQ  #vertical-dimension  {33600} 

-  ANSI  F  Landscape  ~ 

I  REQ  #horizontal-dimension  {13200},  REQ  #vertical-dimenslon  {108000} 

-  ANSI  G  Portrait  ~ 

I  REQ  #horlzontal-dlmension  {108000},  REQ  #vertical-dimenslon  {13200} 

-  ANSI  G  Landscape  ~ 

I  REQ  #horlzontal-dimension  {33600},  REQ  #vertical-dimension  {171600} 

~  ANSI  H  Portrait  - 
I  REQ  #horlzontal-dimension  {171600},  REQ  #vertical-dimension  {33600} 

-  ANSI  H  Landscape  - 

I  REQ  #hori2ontal-dimension  {40800},  REQ  #vertical-dimension  {211200} 

~  ANSI  J  Portrait  - 
I  REQ  #horizontal-dimension  {211200},  REQ  #vertical-dimension  {40800} 

-  ANSI  J  Landscape  - 

I  REQ  #horlzontal-dimension  {48000},  REQ  #vertical-dimension  {171600} 

~  ANSI  K  Portrait  - 
I  REQ  #hori2ontal-dimension  {171600},  REQ  #vertical-dimension  {48000} 

~  ANSI  K  Landscape  ~ 
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-  Foldouts  - 


I  REQ  #hoi1zontai-dimension  {13200},  REQ  #vertical-dimension  {16800} 

-  Foldout  Portrait  - 

I  REQ  #horizontal-dimension  {16800},  REQ  #vertical-dimension  {13200} 

-  Foldout  Landscape  - 

I  REQ  #horizontal-dimenston  {13200},  REQ  #vertlcal-dimension  {>=  16801} 

~  Any  portrait  size  larger  than  tlie  typical  foldout  size  (11  in  x  14  in)  including  11  inch  roll  paper  - 

I  REQ  #horizontal-dimension  {>=  16801},  REQ  #vertlcal-dimenston  {13200} 

~  Any  landscape  size  larger  than  the  typical  foldout  size  (14  In  x  1 1  in)  including  1 1  inch  roll  paper  - 


~  Macro  defining  permissible  code  extension  announcers  - 

DEFiNE(CDEXTEN,  "  ESC  02/00  05/00,        -  LSO - 
(ESC  02/00  05/03],      --  LSRI  - 
[ESC  02/00  05/05],      -  LSR2  - 
[ESC  02/00  05/07],      -  LSR3 - 
[ESC  02/00  05/10],         SS2  - 
[ESC  02/00  05/11]  ~SS3- 


--  Macro  defining  permitted  graphic  renditions  ~ 

DEFINE(GRAPHICRENDITIONS  " 

{'cancel'  |  'increased-intensity' 
I  'italicised'  |  'underlined'  |  'crossed-out' 
I  'primary-font'  |  'first-alternative-font' 
I 'second-alternative-font' I 'third-aiternative-font' 
I  'fourth-aiternative-font'  |  'fifth-alternative-font' 
I  'sixth-alternative-font'  1  'seventh-alternative-font' 
I  'eighth-aiternative-font'  |  'ninth-alternative-font' 
j 'doubly-underlined' I 'normal-intensity' 
{ 'not-italicised'  |  'not-underlined'  |  'not-crossed-out'}... 

") 


-  Macros  defining  final  character  for  designation  ~ 

DEFINE(FCORE.  "04/02  ~  the  94  characters  of  the  IRV  of  ISO  646 
(revised  1990)  (i.e.,  ASCII)  -") 

DEFINE(F646.   "-■  a  final  character  designating  any  version  of  ISO  646 
except  04/02  ~") 

DEFINE(F94S,      a  final  character  designating  any  registered  94  single 
byte  graphic  character  set  --") 
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DEFINE(F94M.      a  final  character  designating  any  registered  94  multi 
byte  graphic  character  set  - ") 

DEFINE(F96S,      a  final  character  designating  any  registered  96  single 
byte  graphic  character  set  --") 

DEFINE(F96M.      a  final  character  designating  any  registered  96  multi 
byte  graphic  character  set 

DEFINE(FEMPTY.  "07/14  -  the  empty  set  -") 

~  Macros  defining  designation  sequences  ~ 

DEFINE(DEG-CORE-GO.  "ESC  02/08  $FCORE") 

~  Designate  the  94  characters  of  the  IRV  of 
ISO  646  to  GO  - 

DEFINE(DEG-646-GO.   "ESC  02/08  $F646") 

-  Designate  any  version  of  ISO  646,  except  04/02, 
toGO- 

DEFINE(DEG-ANY-G1 ,   "{ESC  02/09  $F94S 
1  ESC  02/04  02/09  $F94M 
|ESC02/13$F96S 
I  ESC  02/04  02/13  $F96M}") 

-  Designate  any  cliaracter  set  to  G1  ~ 

DEFINE(DEG-ANY-G2.   "{ESC  02/10  $F94S 
I  ESC  02/04  02/10  $F94M 
|ESC02/14$F96S 
I  ESC  02/04  02/14  $F96IVI}") 
~  Designate  any  character  set  to  G2  ~ 

DEFINE(DEG-ANY-G3,   "{ESC  02/1 1  $F94S 
I  ESC  02/04  02/11  $F94M 
I  ESC  02/15  $F96S 
I  ESC  02/04  02/1 5  $F96M}") 

-  Designate  any  character  set  to  G3  - 

DEFINE(DEG-EMPTY-G1,  "ESC  02/09  $FEI\/IPTY") 

-  Designate  the  empty  set  to  G1  - 

~  Macros  defining  shift  functions  - 

DEFINE(LSO,    "00/15")        ~  locl<ing  shift  invol<ing  GO  to  GL  - 
DEFINE(LS1R,   "ESC  07/14")    -  locking  shift  invoking  Gl  to  GR  - 
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DEFINE(LS2R,  "ESC  07/13")    -  locking  shift  invoking  G2  to  GR  ~ 

DEFINE(LS3R.  "ESC  07/14")    -  iocking  shift  invoking  03  to  GR - 

DEFINE(SS2.  "08/14")       -  single  shift  Invoking  G2  to  GL  ~ 

DEFINE(SS3.  "08/1 5")       -  single  shift  invoking  G3  to  GL  - 

~  Macro  defining  pennlssllsle  graphic  character  sets.  -- 

DEFINE(PERMIT-GRCHAR,  "  {$DEG-CORE-GO  $LSO 
|$DEG-646-G0$LS0}, 
{$DEG-ANY-G1  $LS1R 

|$DEG-ANY-G2$LS2R 

|$DEG-ANY-G3$LS3R}... 
|{$DEG-EMPTY-G1$LS1R}  ") 

-  Macro  defining  default  graphic  character  sets  ~ 
DEFINE(DAP-DEFAULT-GRCHAR.  "$PERMIT-GRCHAR") 

-  Macro  defining  basic  character  sets.  Note  that  this  niacro  is  defined 

for  ciarificatk)n  of  the  specification  arxJ  Is  not  to  be  used  in  any 
other  part  of  this  DAP  specification.  ~ 

DEFINE(BASIC-GRCHAR,  "  $DEG-CORE-G0  $LSO, 
$DEG-EMPTY-G1  $LS1R  ") 

-  Macro  defining  non-t)aslc  character  sets  - 

DEFiNE(NON-BASIC-GRCHAR,  "  {$DEG-646-G0 
|$DEG-ANY-G1 
|$DEG-ANY-G2 
|$DEG-ANY-G3}...  ") 

~  Macro  defining  character  sets  used  in  document  profile  attributes 

DEFINE(PROFCHAR. "  {$DEG-CORE-G0  $LS0, 
|$DEG-646-G0$LS0}, 
{$DEG-ANY-G1  $LS1R 
|$DEG-ANY-G2$LS2R 
|$DEG-ANY-G3$LS3R 
|$DEG-EMPTY-G1  $LS1R}  ") 
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-  Macro  defining  comments  character  sets  - 

DEFiNE(COMCHAR.  "  {ESC  02/00  05/00, 

[ESC  02/00  05/03],  -  LSRI 
[ESC  02/00  05/05],  ~  LSR2 
[ESC  02/00  05/07],  -  LSR3 
[ESC  02/00  05/10],  -  SS2  • 
[ESC  02/00  05/11]}.  -SS3 

{$DEG-CORE-G0  [LSO] 
|$DEG-646-G0  [LSO]}, 

{{$DEG-ANY-G1  [$LS1R] 
|$DEG-ANY-G2  [$LS2R] 
|$DEG-ANY-G3  [$LS3R]}... 
|$DEG-EMPTY-G1  $LS1R}}  ") 


~  Macro  defining  character  sets  used  for  alternative  representation  ~ 
DEFINE(ALTCHAR,  "SPROFCHAR") 


7.1.2       Constituent  constraints 


7.1.2.1  DocumentProfile 

{ 

~  Presence  of  document  constituents  - 

REQ     Specific-layout-structure  {'present'}, 

PERM   Generic-layout-structure  {'factor-set'}, 

PERM   Presentation-styles  {'present'}, 

PERM   Resource-document  {ANY  VALUE}, 

PERM   Resources       {MUL  {REQ  #resource-identifier  {ANY  VALUE}. 

REQ  #resource-ob]ect-class-ldentifier  {ANY_VALUE}}}, 

~  Document  characteristics  ~ 

REQ    Document-appiication-profile  {-  See  clause  8  for  a  definition  of  the  permitted  values  for 

this  attribute.  -}, 

REQ     Document-application-proflle-defaults  { 

I    ~  Document  architecture  defaults  - 

REQ     #content-architecture-class  {$FPR}, 

PERM   #dimensions  {$PermissiblePageDimensions}. 

PERM   #medium-type  { 


December  1992  (Stable) 


-LSO- 
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PERM  #nominal=page-size 
PERM  #side-of-sheet 


{$NominalPageSizes}. 
{ANYVALUE}}, 


-  Any  permitted  medium  type.  Botli  landscape  and  portrait  may  be  specified.  - 

REQ     #type-of-coding  {ASN.1  {2  8  3  7  0}  -  T6  encoding  - 

I  ASN.1  {2  8  3  7  5}  -  tiled  encoding  - 
i  ASN.1  (28376}  ~  T6  encoding  -  MSB 

PERM   #page-position  {ANYVALUE}, 

PERM  raster-graphics-contents-defaults  { 


PERM 
PERM 


}. 


PERM 
PERM 
PERM 


#pel-path 

#line-progression 

#pel-spacing 


{ANYVALUE}, 
{ANYVALUE}, 
{REQ  #lengtii  {ANY  VALUE}. 
REQ  #pei-spaces  {ANY_VALUE}}, 

PERM  #spacing-ratio 

{REQ  #line-spacing-value       {ANY  VALUE}, 
REQ  #pei-spacing-value         {ANY  VALUE}}. 
PERM   #compression  {ANYVALUEf}, 
#geometric-graphics-content-defaults  {ANY_VALUE}. 


#character-content-defaults 
PERM  #alignment 
PERM  #character-spacing 
PERM  #character-fonts 
PERM  #character-orientation 
PERM  #character-path 


{ 


{ANYVALUE}, 
{ANYVALUE}. 
{ANYVALUE}, 
{'0-degrees'  |  '90-degrees'}, 
{'0-degrees'     |  '90-degrees' 
'270-degrees'}, 
PERM  #code-extension-announcers  {$CDEXTEN}, 
PERM  #graphic-ciiaracter-sets  {$PERMIT-GRCHAR}. 
PERM  #graphic-character-subrepertoire  {ANY  VALUE}. 
PERM  #graphic-rendition  {$GRAPHICRENDITIONS}. 
PERM  #line-progression        {'90-degrees'  |  '270-degrees'}, 
PERM  #iine-spacing  {ANY_VALUE}. 
PERM  #iine-layout-table         {ANY  VALUE}}. 


'180-degrees' 


End  of  document  arciiitecture  defaults  ~ 


REQ  Document-architecture-class 
REQ  Content-architecture-classes 
REQ  Interchange-format-ciass 


REQ  ODA-version 


{$FDA}. 

{{$FPR  I  $FPG  I  $FC}...}. 

{-  This  attribute  required  only  for  ODIF  interchange.  See 
clause  8  for  a  definition  of  the  permitted  values  for  this 
attribute.  --}, 


{REQ  #standard-or-recommendation    {'ISO  8613'}, 

REQ  #publication-date  {'1991-12-31'}}, 

~  This  date  represents  the  date  that  this  DAP  was  approved.  This  is  the  only 
~  approved  value,  however,  the  date  will  be  changed  if  the  DAP  is  significantly 
~  revised.  If  the  date  is  revised,  use  of  the  new  date  is  required  only  when  the 
~  additional  functionality  is  being  used.  That  is,  legacy  products  may  continue  to 
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-  Non-basic  document  characteristics  -- 

PERM  ProfMe-character-sets  {$PROFCHAR}. 

PERM  Comments-character-sets  {SCOMCHAR}, 

PERM  Altemative-representation-character-sets  {$ALTCHAR}, 

PERM  Page-dimensions  {MUL  {SNonBasicPageDimenslons}}. 

PERM  Medium-types  {MUL{ 

PERM   #nominal-page-si2e  {$NominalPageSizes}, 

PERM   #side-of-sheet  {ANYVALUE}}}. 

-  All  values  of  "medium  type"  are  non-basic  - 
PERM  Coding-attributes  { 

REQ  #raster-graphics-coding-attributes  { 

REQ  #compression  {'uncompressed'}}}. 
PERM  Presentation-features  { 

PERM   #character-presentation-features     {  MUL  { 

I  PERM  #character-orientation  {'90-degrees'} 

I  PERM  #ciiaracter-path  {'90-degrees',  '180-degrees',  '270-degrees'} 

I  PERM  #graphic-character-sets         {ANY_VALUE}  EXCEPT  {$BASIC-GRCHAR} 
I  PERM  #graphic-character-subrepertoire  {>0} 

I  PERM  #line-spacing  {ANY  VALUE}  EXCEPT  {150.200.300.400} 

I  PERM  #line-progression  {'90-degrees'}}} 
PERM  #Raster-graphics-presentation-features    {  MUL  { 
I  PERM  #pel-path        {'180-degrees'  | 

'270-degrees'} 
I  PERM         #line-progression  {'90-degrees'} 

I  PERM  #pel-spacing    {REQ  #length  {ANY  VALUE}  EXCEPT  {16.12,8.6.5.4.3.2,1 }, 

REQ  #pel-spaces  {ANY  VALUE}  EXCEPT  {1}} 

I  PERM  #spacing-ratio 

{REQ  #line-spacing-value        {ANY_VALUE}  EXCEPT  {1}. 
REQ  #pel-spacing-vaiue         {ANY_VALUE}  EXCEPT  {1 }}}}}, 

-  End  of  Non-basic  characteristics  ~ 
~  Additional  document  characteristics  ~ 

PERM  Fonts-list         {MUL    {REQ  #font-identifier  {ANY  VALUE}. 

REQ  #font-reference  {ANY_VALUE}}}, 

-  The  format  of  the  parameter  "font-reference"  is  defined  in  annex  B  - 


~  Document  management  attributes  - 

-  Document  description  -- 

PERM  Titie  {ANY  STRING}. 

PERM  Subject  {ANY  STRING}, 

PERM  Document-type  {ANY  STRING}. 

PERM  Abstract  {ANY  STRING}. 
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PERM  Keywords 

REQ  Document-reference 

~  Dates  and  times  - 

PERM  Document-date-and-tlme 

PERM  Creation-date-and-time 

PERM  Local-fHing-date-and-time 

PERM  Expiry-date-and-time 

PERM  Start-date-and-time 

PERM  Purge-date-and-tlme 

PERM  Release-date-and-time 

PERM  Revision-history 

-Originators  - 
PERM  Organizations 
PERM  Preparers 
PERM  Owners 
PERM  Authors 

-  Other  user  information  - 
PERM  Copyright 

PERM  Status 

PERM  User-specific-codes 

PERM  Distribution-list 

PERM  Additional-information 

~  External  references  ~ 
PERM  References-to-other-documents 
PERM  Superseded-documents 

~  Local  file  references  ~ 
PERM  Local-file-references 

~  Content  attributes  - 
PERM  Document-size 
PERM  Number-of-pages 
PERM  Languages 

-  Security  information  ~ 
PERM  Authorization 

PERM  Security-classification 
PERM  Access-rights 

} 


{ANYVALUE}. 
{ANYVALUE}. 


{ANYSTRING}, 
{ANY  STRING}. 
{ANY'STRING}, 
{ANY'STRING}. 
{ANY_STRING}. 
{ANYSTRING}. 
{ANY_STRING}. 
{ANY_VALUE}. 


{ANYSTRING}. 
{ANYVALUE}, 
{ANYVALUE}, 
{ANYVALUE}, 


{ANYVALUE}, 

{ANYSTRING}, 

{ANYSTRING}, 

{ANY_VALUE}, 

{ANYVALUE}, 


{ANYVALUE}, 
{ANYVALUE}, 


{ANYVALUE}, 


{ANYVALUE}. 

{ANYJNTEGER}, 

{ANYSTRING}. 


{ANY_VALUE}, 

{ANYSTRING}, 

{ANYSTRING} 
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7.3     Layout  constituent  constraints 


7.3.1       Macro  definitions 


DERNE(CHAR."         CONTENT  ID  OF(Character-content-portion)") 
DERNE(RAST,"  CONTENT~ID~OF(Raster-graphics-content-poitlon)") 
DERNE(GEOM.'  CONTENTJD_OF(Geometric-graphics-content-portion)") 


7.3.2       Factor  constraints 

FACTOR:         ANY-LAYOUT  { 

SPEORC: 

PERM  Object-type 

REG  Object-identifier 

PERM  Subordinates 

PERM  User-vlsible-name 

PERM  User-readable-comments 
} 


7.3.3      Constituent  constraints 


7.3.3.1  DocumentLayoutRoot 

DocumentLayoutRoot:  ANY-LAYOUT  { 
SPECIRC: 

REG    Object-type  { 'document-layout-roof}, 

REG    Subordinates  {SUB_ID_OF(ComposrtePage)  + } 

} 

7.3.3.2  CompositePage 

ComposltePage:  ANY-LAYOUT  { 

SPECIFIC: 
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REQ  Object-type 

REQ  Subordinates 

PERM  Dimensions 

PERM  Page-position 

PERM  Medium-type 

PERM  Imaging-order 

PERM  Application-comments 
} 


{'page'}. 

{SUBJD_OF(Origlnallmage). 
[SUBJD_OF(RevisionAnnotatlon) + 1 }, 
{SPemnissibiePageDimensions}, 
{ANY_VALUE}. 

{REQ  #nomlnal-page-size  {$NominalPageSizes}, 
REQ  #slda-of-sheet  {ANY_VALUE}}. 
{ANY_VALUE}. 
{ANYVALUE} 


7.3.3.3  Origlnallmage 

Originailmage: 

SPECIFIC: 
REQ  Object-type 
REQ  Subordinates 
PERM  Position 

PERM  Dimensions 


PERM  Application-comments 
} 


ANY-U^YOUT  { 


{'frame'}. 

{SUBJD_OF(SpeclflcBlocl<)  +  }. 
{REQ  #fixed-F)osition 

{REQ  #horlzontal-position  {ANY  VALUE}, 

REQ  #vertical-position  {ANY  VALUE}}}. 
{REQ  #liorizontal-dimension 

{REQ  #flxed-dimenslon{ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dimension{ANY_VALUE}}}. 
{ANYVALUE} 


7.3.3.4  RevlslonAnnotatlon 

RevisionAnnotation:  ANY-LAYOUT 

SPECIFIC: 
REQ  Object-type 
REQ  Subordinates 
PERM  Position 


PERM  Dimensions 


PERM  Application-comments 


{ 


{'frame'}. 

{SUBJD_OF(SpeclflcBlock) }, 
{REQ  #flxed-positlon 

{REQ  #horlzontal-posltion  {ANY  VALUE}. 

REQ  #vertical-posltlon  {ANY  VALUE}}}, 
{REQ  #horizontal-dlmenslon 

{REQ  #flxed-dlmenslon{ANY_VALUE}}, 
REQ  #vertlcal-dlmension 

{REQ  #flxed-dimension{ANY_VALUE}}}. 
{ANYVALUE}} 
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7.3.3.5 


SpeclficBlock 


SpeclficBlock: 

SPECIFIC: 
REQ  Object-type 
REQ  Object-identifier 
REQ  Content-portions 
PERM  Position 


PERM  Dimensions 


{ 


PERM  Object-ciass 

PERM  Content-architecture-class 

PERM  Transparency 

PERM  Colour 

PERM  User-readable-comments 

PERM  User-visible-name 

PERM  Application-comments 

PERM  Presentation-style 

-  PStylel  for  character 

PERM  Presentation-attributes 


{'block'}. 

{ANYVALUE}. 

{$CHAR  I  $RAST  |  $GEOM}, 

{REQ  #fixed-position  { 

REQ  #horlzontal-position  {ANY  VALUE}. 

REQ  #vertlcal-position  {ANY  VALUE}}}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension{ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension{ANY_VALUE}}}, 
{OBJECT_CLASS_ID_OF(GenericBlock)}. 
{$FC  I  $FPR  I  $FPG}, 
{'transparent'  |  'opaque'}, 
{'colourless'  |  'white'}, 
{ANYSTRING}. 
{ANYSTRING} 
{ANYVALUE}, 
~  See  8.1.3  and  8.2.3  ~ 

{STYLE_ID_0F(PStyle1) 
STYLEJD_0F(PStyle3}, 
content,  PStyle2  for  geometric,  &  PStyle3  for  raster 
{ 


STYLEJD_0F(PStyle2) 


CASE  SpecificBlock(Content-portions)  OF  { 


{$CHAR}: 

{PERM 


#character-attributes 
PERM  #alignment 
PERM  #character-spacing 
PERM  #character-fonts 
PERM  #character-orientatlon 
PERM  #character-path 


{ 


PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 


{ANYVALUE}, 
{ANYVALUE}. 
{ANYVALUE}, 
{'0-degrees'  |  '90-degrees'}. 
{'0-degrees'     |  '90-degrees' 
'270-degrees'}, 
#code-extension-announcers  {$CDEXTEN}. 
#graphic-character-sets  {$PERMIT-GRCHAR}, 
#graphlc-character-subrepertoire  {ANY_VALUE}, 


'180-degrees' 


}} 

{$RAST}: 


#graphic-rendition 
#line-progression 
#iine-spacing 
#iine-layout-table 


{$GRAPHICRENDITIONS}, 
{'90-degrees'  |  '270-degrees'}, 
{ANYVALUE}. 
{ANYVALUE}. 


{PERM  #raster-graphics-attributes 
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PERM  #Pei-path 
PERM  #Une-progression 
PERM  #Pel-spacing 
PERM  #Spacing-ratio 

PERM  #aipping 


{$GEOM}: 

{PERM 


}}} 


{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE}. 

{REQ  #llne-spacing-value  {ANY_VALUE}. 
REQ  #pel-spacing-value  {ANY_VALUE}}. 
{ANY_VALUE}}} 


#geometric-graphics-attributes  { 
PERM  #picture-dimension8  {ANY_VALUE}, 
PERM  #picture-orientation 
PERM  #text-rendition 


{ANY_VALUE>. 

{PERM  #fonts-list  {ANY_VALUE}. 
PERM  #character-set-lists  {ANY  VALUE}}} 


7.3.3.6 


GenericBlock 


GenericBlock 


GENERIC: 
REQ  Object-type 
REQ  Content-portions 
PERM  Position 


PERM  Dimensions 


REQ  Object-dass-identifier 

PERM  Resource 

PERM  Content-architecture-ciass 

PERM  Transparency 

PERM  Colour 

PERM  User-readable-comments 

PERM  User-visible-name 

PERM  Application-comments 

PERM  Presentation-style 

-  PStylel  for  character 

PERM  Presentation-attributes 


{'block'}, 

{$CHAR  I  $RAST  |  $GEOM}. 
{REQ  #fixed-position  { 

REQ  #horizontal-position  {ANY  VALUE} 

REQ  #verticai-position  {ANY_VALUE}}}. 
{REQ  #horizontai-dimension 

{REQ  #fixed-dimension{ANY_VALUE}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension{ANY_VALUE}}}, 

{ANYVALUE}, 
{ANYVALUE}, 
{$FC  I  $FPR  I  $FPG}. 
{'transparent'  |  'opaque'}, 
{'colourless'  |  'wliite'}, 
{ANYSTRING}, 
{ANY-STRING} 
{ANYVALUE}, 
~  See  8  2  — 

{STYLEJD_0F(PStyle1) 
STYLEJD_0F(PStyie3}, 
content,  PStyle2  for  geometric,  &  PStyle3  for  raster 

{ 


STYLE  ID  0F(PStyle2) 


CASE  GenericBlock(Content-portions)  QF  { 

{$CHAR}: 

{PERM  #character-attributes 
PERM  #aiignment 


{ 

{ANY_VALUE}. 
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PERM 
PERM 
PERM 
PERM 

PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 


#character-spacing  {ANYVALUE}. 
#character-fonts  {ANYVALUE}. 
#character-orientation  {'0-degrees'  |  '90-degrees'}, 
#character-path  {'0-degrees'     |  '90-degrees' 

'270-degrees'}. 
#code-extension-announcers  {$CDEXTEN}, 
#graphic-character-sets  {$PERMIT-GRCHAR}, 
#graphic-character-subrepertoire  {ANY  VALUE}, 


I     'ISO-degrees'  | 


}> 

{$RAST}: 

{PERM 


#graphic-rendition 
#line-progression 
#line-spacing 
#line-layout-table 


#raster-graphics-attributes 
PERM  #Pel-path 
PERM  #Une-progression 
PERM  #Pel-spacing 
PERM  #Spacing-ratio 


PERM  #Clipping 


{$GRAPHICRENDITIONS}, 
{'90-degrees'  |  '270-degrees'}, 
{ANYVALUE}, 
{ANY_VALUE}, 


{ 

{ANY_VALUE}, 
{ANY  VALUE}, 
{ANY~VALUE}, 

{REQ  #line-spacing-value  {ANY  VALUE}, 
REQ  #pel-spacing-value  {ANY_VALUE}} 
{ANYVALUE}}} 


{$GEOM}: 

{PERM 


#geometric-graphics-attributes 
PERM  #picture-dimensions 
PERM  # picture-orientation 
PERM  #text-rendition 


}}} 


{ 

{ANY_VALUE}, 
{ANY  VALUE}, 

{PERM  #fonts-list  {ANY  VALUE}, 

PERM  #character-set-list"s  {ANY_VALUE}}} 


7.4  Layout  style  constraints 

No  layout  style  constraints  applicable  in  this  clause. 

7.5  Presentation  style  constraints 


7.5.1       Macro  definitions 

No  macro  definitions  are  applicable  to  this  clause. 
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7.5.2       Factor  constraints 


FACTOR:         ANY-PRESENTATION-STYLE  { 

REQ    Presentation-style-identifier  {ANY  VALUE}. 

PERM  User-readable-comments  {ANY~STRING}, 

PERM  User-vlsiWe-name  {ANY  STRING}, 

} 


7.5.3  Presentation  style  constituent  constraint 
7.5.3.1  PStylel 

PStylel:  ANY-PRESENTATION-STYLE  { 


~  This  style  is  used  for  character  content  ~ 


PERM  Presentation-attributes 

PERM  #character-attributes 
PERM  #alignment 
PERM 
PERM 
PERM 
PERM 


PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 


{ANYVALUE}. 
{ANYVALUE}, 
{ANYVALUE}. 
{'0-degrees'  |  '90-degrees'}. 
{'0-degrees'     |  '90-degrees' 
'270-degrees'}. 
#code-extension-announcers  {$CDEXTEN}, 
#graphic-character-sets  {$PERMIT-GRCHAR}. 
#graphic-character-subrepertoire  {ANY_VAHJE}. 


#character-spacing 
#character-fonts 
#character-orientation 
#character-path 


I  '180-degrees' 


#graphic-rendition 
#line-progression 
#line-spacing 
#line-layout-table 


{$GRAPHICRENDITIONS}. 
{'90-degrees'  |  '270-degrees'}. 
{ANYVALUE}. 
{ANYVALUE}}} 


7.5.3.2  PStyle2 

PStyle2:  ANY-PRESENTATION-STYLE  { 

~  This  style  is  used  for  geometric  graphics  content  - 

PERM  Presentation-attributes  { 

PERM  #geometric-graphics-attributes  { 

PERM  #picture-dimensions  {ANY  VALUE}, 

PERM  #picture-orientation  {ANY  VALUE}. 

PERM  #text-rendition  {PERM  #fonts-list{ANY_VALUE}. 
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PERM  #character-set-list{ANY_VALUE} } } } 


7.5.3.3  PStyle3 

PStyle3:  ANY-PRESENTATION-STYLE  { 

-  This  style  is  used  for  raster  graphics  content  -- 

PERM  Presentation-attributes  { 

PERM   #raster-graphics-attributes  { 

PERM  #pel-path  {ANY_VALUE}. 
PERM  #line-progression  {ANY_VALUE}, 
PERM  #pel-spacing  {REQ  #length  {ANY  VALUE}, 

REQ  #pel-spaces  {ANY  VALUE}}. 
PERM  #spaclng-ratio   {REQ  #iine-spacing-value  {ANY  VALUE}. 

REQ  #pel-spacing-value  {ANY_VALUE}}. 
PERM  #clipping  {ANY  VALUE}}} 

} 


7.6      Content  portion  constraints 


7.6.1       Macro  definitions 

DEFINECriLED,"         ASN.1  {2  8  3  7  5}")  -  Tiled  raster  encoding  - 


7.6.2       Factor  constraints 

No  factor  constraints  are  applicable  to  this  clause. 


7.6.3       Constituent  constraints 


7.6.3.1        Character  content  portion 

Character-content-portion  { 

REQ     Content-identifier-layout  {ANYVALUE}, 
PERM  Type-of-coding  {ASN.1  {2  8  3  6  0}}, 

PERM  Alternative-representation  {ANY  STRING}. 

PERM  Content-information 

{CHARACTER,  {#STAB  {ANY  VALUE} 
|#SHS  {ANYVALUE} 
|#SGR  {$GRAPHICRENDITIONS} 
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{ANYVALUE} 
{ANYVALUE} 
{ANYVALUE} 
{ANYVALUE} 


|#SVS 
|#SLS 
|#SCS 
|#SRS 
|#CR 
|#LF 
|#PLD 
|#PLU 
|#SP 
1#SUB 
|#LSO 
|#LS1R 
|#LS2R 
|#LS3R 
|#SS2 
j#SS3 

|#$DEG-CORE-G0 

|#$DEQ-646-G0 

|#$DEG-ANY-G1 

|#$DEG-ANY-G2 

|#$DEG-ANY-G3 

|#$DEG-EMPTY-G1 

}...} 


7.6.3.2 


Raster  graphics  content  portion 


Raster-graphics-content-portion  { 
REQ  Content-identifier-layout 
PERM  Type-of-coding 


{ANYVALUE}. 
{  ASN.1{2  83  70} 
I  ASN.1{2  83  7  1} 
I  ASN.1{2  83  72} 
I  ASN.1{2  83  73} 
1  ASN.1{2  83  7  5} 
I  ASN.1{2  83  76} 
I  ASN.1{2  83  7  7} 
I  ASN.1{2  83  7  8} 

PERM  Coding-attributes  { 

REQ     #raster-graphics-coding-attributes  { 
PERM  #compression 
PERM  #numt)er-of-lines 
REQ  #numl)er-of-pels-per-line 
CASE  Raster-graphics-content-portion 


~  T.6  encoding  - 

~  T.4  one  dimensional  ~ 

-  T.4  two  dimensional  ~ 
~  bitmap  ^coding  ~ 

~  tiled  encoding  ~ 

-  T.6  encoding  -  MSB  - 

~  T.4  one  dimensional  -  MSB 

-  T.4  two  dimensional  -  MSB 


{ANY_VALUE}. 

{>0}. 

{>0}. 
(Type-of-coding)  OF  { 


{$TILED}:       {PERM  #number-of-pels-per-tile-line 
PERM  #numl5er-of-lines-per-tlle 
PERM  #tiiing-offset 
PERM  #tile-types 


{512}. 
{512}. 

{ANY_VALUE}. 
{^nuli  background' 


}. 
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PERM  Alternative-representation 
PERM  Content-infomnation 
} 


'null  foreground'  | 
T.6  encoded'  | 
'bitnnap  encoded'  | 
T.6  encoded  -  MSB'}}}}, 


{ANYSTRING}. 
{RASTER} 


7.6.3.3 


Geometric  graphics  content  portion 


Geometric-graphics-content-portion 

REQ  Content-identrfier-iayout 

PERM  Type-of-coding 

PERM  Alternative-representation 

PERM  Content-inforniation 

> 


{ 


{ANYVALUE}, 
{ASN.1{2  83  80}}. 


{ANYVALUE}. 
{GEOMETRIC} 


7.7     Additional  usage  constraints 

No  other  usage  constrain^  are  currently  defined. 


8    Interchange  format 

Two  interctiange  fomnats  are  supported  by  this  profile.  The  interchange  format  ODIF  (class  A)  can  be  used 
by  applications  requiring,  a  binary  encoding  based  on  ASN.1.  The  Interchange  Format  SDIF  can  be  used 
by  applications  requiring  a  SGML  based  clear  text  encoding.  This  latter  interchange  format  is  an  SGML 
application,  called  Office  Document  Language  (ODL).  For  the  purposes  of  interchange,  the  ODL  EfslTITiES 
are  placed  in  an  ASN.1  wrapper,  as  defined  by  SDIF.  Each  encoding  form  has  inherent  advantages. 
Conversion  of  document^ encoded  in  one  interchange  format  into  the  other  should  not  produce  the  loss  of 
semantic  document  information. 


8.1      Interchange  format  ODIF  (class  A) 
8.1.1       Interchange  format 

The  value  of  the  document  profile  attribute  "interchange  fonnat"  for  this  interchange  fonnat  is  'If-a'.  This  form 
of  ODIF  is  defined  in  ISO  8613-5. 

The  encoding  is  in  accordance  with  the  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1), 
as  defined  in  ISO  8825. 


f 
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The  value  for  the  document  profile  attribute  'document  application  profile"  for  this  interchange  fomnat  is 
represented  by  the  following  object  Identifier. 

Editor's  Note  -  To  be  supplied. 


8.1.3       Encoding  of  application  comments 

ISO  8613-5  define  the  encoding  of  the  attribute  'application  comments'  as  an  octet  string.  For 
SpecificBlock.  this  DAP  requires  that  the  encoding  within  that  octet  string  be  In  accordance  with  the  ASN.1 
syntax  specified  in  the  following  module  definition. 

NIST-DAPSpecificatSon 

DEFINITIONS  ::=  BEGIN 

EXPORTS  Object-Appl-Comm-Encoding; 

Objecl-Appl-Comm-Encoding  ::=  SEQUENCE  OF  INTEGER 
END 


8.2      Interchange  format  SDIF 


8.2.1       Interchange  format 

The  document  profile  attribute  "interchange  format"  does  not  apply  for  this  interchange  format.  The  SDIF 
encoding  of  ODA  is  defined  in  Annex  E  of  ISO  8613-5.  In  addition,  ISO  8613-6,  -7,  and  -8  contain  additional 
specifications  for  this  encoding  of  ODA. 


8.2.2       DAP  identifier 

The  value  for  this  attribute  "document  application  profile*  for  this  interchange  format  is  represented  by  the 
following  object  identifier. 

Editor's  Note  -  To  be  supplied.  ^ 


8.2.3       Encoding  of  application  comments 

For  SpecificBlock,  the  encoding  of  the  attribute  "application  comments"  is  defined  in  a  data  stream 
conforming  to  this  profile  with  the  following  DTD  definition: 

< !~  The  following  set  of  declarations  may  be  Invok^j  by  using  a  public  entity  as  follows: 

<  IDOCTYPE  odaac  Public  "-//USA-OIW//DTD  SGML  ENCODiNG  ODA  APPLICATION  COMMENTS//EN"  > 
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-> 

<!-  NOTE:  To  parse  the  following  Document  Type  Declaration  Subset,  place  the  Document  Type 
declaration'  <IDOCTYPE  odaac  ['  at  the  beginning  of  the  file  and  ']>'  at  the  end  of  the  file.  ~> 

<  I  ELEMENT  odaac  -  -  (obJappc)+  > 

<l~  Object  appllcatton  comment  -> 

<  lELEMENT  objappc  -  O  (#PCDATA)  > 

8.3     Encoding  of  raster  content  information 

The  encoding  of  raster  content  Information  In  the  bitmap  encoding  scheme  is  that  specified  in  9.3  of  the 
raster  graphics  content  architecture  part  of  ISO  8613-7,  tliat  is,  the  first  pel  in  the  order  of  bits  is  allocated 
to  the  nfK>st  significant  bit  of  an  octet.  The  encoding  of  the  code  words  in  the  CCITT  Recommendation  T.4 
and  T.6  encoding  schemes  may  be  done  in  either  the  up  or  down  bit  order.  The  bit  order  is  specified  by 
the  attributes  "type  of  coding"  or  "tile  types".  The  attribute  "tile  types'  is  used  only  when  the  value  for  "type 
of  coding'  is  tiled  encoded*.  For  the  up  order,  it  is  such  that  the  first  or  only  bit  of  the  first  code  word  shall 
be  placed  in  the  least  significant  bit  erf  the  first  octet.  Subsequent  bits  of  the  first  and  following  code  words 
are  placed  in  the  direction  of  more  significant  bits  in  the  first  and  following  octets.  For  the  down  order,  it 
Is  such  that  the  first  or  only  bit  of  the  first  code  word  shall  be  placed  In  the  most  significant  bit  (MSB)  of  the 
first  octet.  Subsequent  bits  of  the  first  and  following  code  words  are  placed  in  the  direction  of  least 
significant  bits  In  the  first  and  following  octets. 
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Annex  A  (normative)   

Amendments  and  corrigenda 

A-1  Amendments 

A.1.1      Amendments  to  the  base  standard 

The  amendments  applicable  to  this  DAP  includes  the  ISO  8613  -  Amendment  1: 1990.  This  amendment 
includes  text  to  be  included  in  ISO  8613-1  as  the  following  annexes: 

a)  Annex  E:  Use  of  ISO/EC  10021  (MOTIS)  to  interchange  documents  confomning  to  ISO  8613; 

b)  Annex  F:  Document  application  profile  proforma  and  notation; 

c)  Annex  G:  Conformance  testing  methodology; 

d)  Annex  H:  Recording  of  documents  conforming  to  ISO  8613  on  flexible  disk  cartridges 
conforming  to  ISO  9293. 

In  addition,  this  amendment  addresses  the  Indusion  of  the  ISO  8613  Technical  Corrigenda  1. 

This  DAP  does  not  include  the  foilowsng  features  of  the  amendment: 

a)  Addendum  on  security; 

b)  Addendum  on  styles; 

c)  Addendum  on  alternative  representation. 

Additionally,  this  DAP  includes  features  from  the  Tiled  Raster  Graphics  Addendum  to  ISO  8613-7.  ISO/IEC 
JTC1/SC18/WG5  901,  dated  September  1990,  and  the  Additional  Bit  Order  Mapping  Addendum  to  CCitT 
Rec.  T.417|ISO  8613-7,  ISO/IEC  JTC  1/WG  3,  dated  July  1991.  A  new  version  of  ISO  8613-7  which  also 
will  incorporate  the  Colour  Addendum  Is  scheduled  to  be  Issued  in  1993. 

A.2  Corrigenda 

A.2.1       Corrigenda  to  this  DAP 
There  are  no  conigenda  to  this  DAP. 
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Annex  B  (informative) 
Recommended  practices 


B.1      Transfer  methods  for  ODA 


B.1.1       Conveyance  of  ODA  over  CCITT  X.400-1984 

This  recommendation  describes  tiow  ODA  body  parts  are  to  be  encoded  for  transmission  over  a  CCITT 
X.400-1984  service. 

An  ODA  body  part  is  encoded  as  OdaBodyPart  in  the  definition  given  below: 


OdaBodyPart  ::=  SEQUENCE  {  OdaBodyPartParameters,  OdaData  } 
OdaBodyPartParameters  ::=  SET  { 
document-application-profile 

[0]  IMPLICIT  OBJECT  IDENTIFIER, 
document-architecture-class 

[1]  IMPLICIT  INTEGER  { 
formatted  (0), 
processable  (1), 
formatted-processaWe  (2)  } 
OdaData  ::=     SEQUENCE  OF  Interchange-Data-Element 


NOTE  -  It  is  recommended  to  transfer  an  ODA  document  as  a  single  body  part  with  tag  12: 
Oda  [12]  IMPLICIT  OCTETSTRING 

The  content  of  the  octet  string  is  encoded  as  OdaBodyPart,  defined  above.  However,  this  is  out 
of  the  scope  of  this  profile. 

B.1 .2       Conveyance  of  ODA  over  FTAM 

This  recommendation  describes  the  File  Transfer,  Access,  and  Management  (FTAM)  Document  Type  to  be 
used  for  minimal  storage  and  transfer  capabilities  of  ODA  data  streams.  It  is  recognized  that  enhanced 
capabilities  may  at  some  point  be  added. 

When  using  FTAM  to  transfer  an  ODA  file,  the  FTAM-3,  "ISO  FTAM  Unstructured  Binary",  document  type 
should  be  specified.  However,  since  files  that  do  not  contain  ODA  data  streams  can  have  the  same 
document  type,  it  is  left  up  to  the  user  of  application  programs  that  remotely  access  files  using  FTAM  to 
know  that  a  given  file  contains  an  ODA  data  stream. 
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B.1.3       Conveyance  of  ODA  over  DTAM 

This  recommendation  provides  for  information  concerning  the  Interchange  of  ODA  based  documents  with 
Document  Transfer  and  Manipulation  (DTAM)  protocols. 

DTAM  is  defined  in  the  T.430-Series  of  recommendations  and  is,  like  ODA,  an  Integral  part  of  the  T.400- 
Series  of  CCITT  Recommendations  named  Open  Document  Architecture,  Transfer  and  Manipulation. 

The  T.520-Serles  of  recommendations  contain  Communication  Application  Profiles  (CAP).  Recommendation 
T.522  describes  the  Communication  Application  Profile  BT1  for  document  bulk  transfer.  Recommendation 
T.522  is  applicable  for  the  Office  Document  Format  Profile  (FOD)  published  In  this  ISP. 

NOTE  -  The  use  of  BT1  within  the  end-to-end  oriented  Telematic  Services  Telefax  4  and  Teletex  is  described 
in  7.1  of  Recommendation  T.561  and  7.1  of  Recommendation  T.562. 

B.1.4      Conveyance  of  ODA  over  flexible  disks 

The  recommended  method  for  Interchanging  ODA  documents  between  systems  by  the  exchange  of 
magnetically  recorded  Flexible  Disk  Cartridges  Is  by  the  use  of  an  annex  to  ISO  8613-1  (to  be  published). 
Receding  of  Documents  Conforming  to  ISO  8613  on  Flexible  Cartridges  Conforming  to  ISO  9293.  This 
annex  provides  for  recording  each  ODA  document  as  a  separate  file  as  defined  by  ISO  9293,  Volume  and 
File  Structure  of  Flexible  Disk  Cartridges  for  Information  Interchange. 

NOTE  -  Document  encoded  in  ODL  can  be  stored  such  that  each  SGML  ENTITY  is  recorded  in  a  separate 
file  or  in  the  case  of  an  SDIF  encoding,  the  file  can  be  stored  in  a  single  file. 

B.2      Font  reference 

The  recommended  method  for  specifying  a  font  reference  is  to  be  based  on  ISO  9541.  Such  a  reference 
is  to  be  specified  by  the  following  ASN.I  encoding. 

Fonts-Fteference      ::=        SET  { 

user-visible-name  (0)  IMPLICIT  Comment-String  OPTIONAL, 

user-readable-comment  (1)  IMPLICIT  Comment-String  OPTIONAL, 
reference-attributes  (2)  IMPLICIT  SET  OF  SET  { 

precedence-number  (0)  IMPLICIT  INTEGER  OPTIONAL, 

attributes  (1)  IMPLICIT  Font-Attribute-Set, 

user-readable-comment        (2)  IMPLICIT  Comment-String  OPTIONAL  } 

} 

Font  sizes  from  6  to  72  points  (100  to  1200  BMU)  are  intended  to  be  supported  by  Implementation 
conforming  to  this  informative  recommendation.  All  other  values  of  font  sizes  may  additionally  be  supported, 
but  Implementations  may  also  support  using  some  form  of  "fallback". 

The  minimum  font  properties  and  values  from  ISO  9541  that  are  to  be  specified  In  a  Font-Attribute-Set  be 
those  specified  by  the  following  document  application  profile  notation. 

Font-Attribute-Set  { 

PERM     Fontname  {ANYVALUE}, 
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PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 


PERM 
PERM 


PERM 


PERM 


PERM 
PERM 


Standardversion 

Dsnsource 

Fbntfamily 

Posture 

Weight 

Propwidth 

Glyphcomp 

PERM  #inclgyphcols 

PERM  #excigyphcols 

PERM  #inclgyphs 

PERM  #exclgyphs 

Dsnsize 

Minsize 

PERM  #nunnerator 
PERM  #denominator 
Maxsize 

PERM  #numerator 

PERM  #denominator 

-  BMU  Units  equivalent  to  range  of  6. 

Dsngroup 

PERM  #group-code 
PERM  #subgroup-code 
PERM  #specific-group-code 
Structure 
Wrmodes 

PERM  #wrmodename 
PERM  #nonf)escdir 
PERM  #e8class 
PERM  #avgescx 
PERM  #avgescy 


{-  To  t>e  supplied  -}, 

{ANYVALUE}, 

{ANYVALUE}. 

{'upright'  I  'italic-fonward'}, 

{'light'  I  'medium'  |  'bold'}, 

{ANYVALUE}, 

{ 

{ANYVALUE}. 

{ANYVALUE}. 

{ANYVALUE}, 

{ANY_VALUE}  }, 
{ANYVALUE}, 
{ 


{1}}. 


{100  ..  1200}, 


{100  ..  1200}, 


{1}}. 
.72  point  sizes  - 

{ 

{ANYVALUE}, 
{ANYVALUE}, 
{ANY  VALUE}  }. 

{ANYVALUE}, 

{ 

{ANYVALUE}, 

{'Ondegrees' 
{ANYVALUE}, 
{ANYVALUE}, 
{ANY  VALUE}  } 


'90^egrees'  |  '180-degrees'  |  '270-degrees'}, 


B.3      ISO  8632  (CGM)  constraints  for  this  DAP 

It  is  recommended  that  geometric  graphics  content  information  contain  oniy  those  elements  listed  in  this 
portion  of  the  document,  in  addition  to  the  constraints  imposed  by  ISO  8613-8.  It  is  believed  that  this  subset 
of  the  CGM  is  sufficiently  implemented  to  enable  intenvorking  of  geometric  graphics  for  application 
corrforming  this  document  application  profile. 

Where  an  element  has  parameters,  recommended  constraints  on  the  values  are  given.  The  symbol 
indicates  that  there  is  no  recommended  constraint. 

Requirements  in  ISO  8632  and  ISO  8613-8  concerning  mandatory  elements,  parameters  must  be  fulfilled. 


B.3.1       Delimeter  elements 

No-Op  See  Note  1 

Begin  Metafile  See  Note  2 

End  Metafile 

Begin  Picture  See  Note  2 

Begin  Picture  Body 
End  Picture 
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B.3.2       Metafile  descriptor  elements 


Metafile  Version 
Metafile  Description 
VDC  Type 
Integer  Precision 
Real  Precision 
Index  Precision 
Colour  Precision 
Colour  Index  Precision 
Maximum  Colour  Index 
Colour  Value  Extent 
Metafile  Element  List 
Font  List 

Character  Set  List 
Character  Coding  Announcer 


1 

See  Notes  2,  3 
8,  16 

(0.9,23),  (1,16,16) 
16 

8,  16 
8,  16 


See  Note  5 

0,  (basic-7-bit),  (basic-8-bit) 


B.3.3       Picture  descriptor  elements 

Scaling  Mode  See  Note  6 

Colour  Selection  Mode 

Line  Width  Specification  Mode  - 
Marker  Size  Specification  Mode  ~ 
Edge  Width  Specification  Mode 
VDC  Extent 

Background  Colour  ~ 


B.3.4       Control  elements 

VDC  Integer  Precision  16,  32 

VDC  Real  Precision  (0,9,23),  (1,16,16) 

Auxiliary  Colour 

Transparency 

Clip  Rectangle 

Clip  Indicator 


B.3.5       Graphical  primitive  elements 

Polyline  See  Note  7 
Disjoint  Polyline  See  Note  7 

Polymarker  See  Note  7 

Text  See  Note  2 
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Restricted  Text  See  Notes  2,  8 

Append  Text  See  Notes  2,  8 

Polygon  See  Note  7 

Polygon  Set  See  Note  7 

Cell  Array  See  Note  9 

Rectangle  - 
Circle 

Circular  Arc  3  Point  ~ 

Circular  Arc  3  Point  Close  - 

Circular  Arc  Centre  ~ 

1  Circular  Arc  Centre  Close  ~ 

Ellipse  - 
Elliptical  Arc 
Elliptical  Arc  Qose 


B.3.6       Attribute  elements 


Line  Bundle  Index 

Line  Type 

Line  Width 

Line  Colour 

Marker  Bundle  Index 

Marker  Type 

Marker  Size 

Marker  Colour 

Text  Bundle  Index 

Text  Font  Index 

Text  Precision 

Character  Expansion  Factor 

Character  Spacing 

Text  Colour 

Character  Height 

Character  Orientation 

Text  Path 

Text  Alignment 

Character  Set  Index 

Alternate  Character  Set  Index 

Fill  Bundle  Index 

Interior  Style 

Fill  Colour 

Hatch  Index 

Pattern  Index 

Edge  Bundle  Index 

Edge  Type 

Edge  Width 

Edge  Colour 

Edge  Visibility 


1-5 
1-5 

positive 

1-5 
1-5 


1-5 


positive 


1-5 


1-6 

1  ..  8,  nx  1-16.  ny  1-16 

1-5 

1-5 

positive 
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Fai  Reference  Point 

Pattern  Table  See  Notes  10,  1 1 

Pattern  Size 

Colour  Table  Specification  See  Notes  12,  13 

Aspect  Source  Rags  - 


B.3.7      External  elements 

Message  No  action 

Application  Data  See  Note  2 


NOTE- 

1 .  An  arbitrary  sequence  of  n  octets.  Where  n =0, 1 , ..,  32767.  The  sequence  of  zero  or  more  octets  is  for  padding 
purposes. 

2.  The  string  ocurring  in  the  parametric  list  of  this  element  shall  not  contain  more  than  254  characters,  except  for 
data  records  where  the  string  shall  not  contain  more  than  32767  characters. 

3.  There  will  be  exactly  one  METAFILE  DESCRIPTION  element  in  the  metafile.  The  METAFILE  DESCRIPTION  string 
parameter  will  be  used  to  include  the  sub-string  "ISO  FCG13"  to  label  the  content  information  as  conforming 
to  this  agreement.  In  addition,  the  METAFILE  DESCRIPTION  element  should  include  a  sub-string  that  identifies 
the  generator  of  this  metafile,  including  company,  product,  and  product  version. 


4.  The  only  character  sets  that  may  be  specified  are  those  specified  for  character  content  portions.  Refer  to  7.1, 
Document  Profile  Constraints,  for  further  detail  on  which  character  sets  are  supported  by  this  document 
application  profile.  The  default  character  set  for  geometric  graphics  content  is  the  same  as  the  default  character 
set  for  character  content  architecture. 

5.  The  Scale  Factor  parameter  of  SCALING  MODE  element  is  always  a  32-bit  floating  point  value,  even  when  the 
REAL  PRECISION  has  selected  fixed  point  for  other  real  numbers.  It  is  not  apparent  in  ISO  8632  what  the 
precision  of  this  floating  point  value  is  when  fixed  point  has  been  selected.  Its  precision  shall  be  (0,9,23). 

6.  The  maximum  number  of  points  of  this  element  shall  be  1024. 

7.  The  complete  restricted  text  string,  including  any  appended  text,  shall  be  included  in  a  metafile  conforming  to 
this  agreement.  The  complete  restricted  text  string  shall  be  scaled  isotropically  such  that  the  specified  aspect 
ratio  for  the  text  is  not  distorted  and  the  string  fits  into  the  text  extent  parallelogram.  String  of  parameters  shall 
not  contain  any  control  characters  except  as  allowed  by  and  necessary  to  implement  the  character  set  switching 
modes  which  can  be  selected  by  basic  values  of  CHAR  CODE  ANNOUNCER. 

8.  The  maximum  numt>er  of  colour  values  that  can  appear  in  the  colour  list  parameter  for  the  CELL  ARRAY 
element  shall  be  1048576  (one  1024  x  1024  image). 

9.  The  PATTERN  TABLE  element  shall  appear  prior  to  any  graphical  primitive  element  to  assure  that  interpreting 
systems  without  dynamic  pattern  update  can  render  the  intended  effect.  Once  a  given  pattern  representation 
is  specified  and  used,  it  shall  not  be  respecified. 

10.  Colour  Array  parameter  for  the  PATTERN  TABLE  element  is  2048.  This  will  support  8  patterns  of  16x16.  The 
maximum  number  of  colour  values  that  can  appear  in  a  colour  array  parameter  shall  be  256  for  each  PATTERN 
TABLE  element  (one  16x16  pattern)  and  2048  for  the  complete  pattern  table  itself  (eight  16x16  patterns). 

1 1 .  The  COLOUR  TABLE  element  shall  appear  prior  to  any  graphical  primitive  elements  to  assure  that  interpreting 
systems  without  dynamic  colour  update  can  render  the  intended  effect.  Once  a  given  colour  representation  is 
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specified  and  used,  it  shall  not  be  respecified.  For  indexed  colour  selection,  either  background  colour  or  all 
colour  indexes  in  the  metafile  shall  have  their  representations  specified  or  none  shall.  Colour  indexes  shall  be 
specified  by  the  COLOUR  TABLE  elennent.  Background  colour  shall  be  specified  either  by  the  BACKGROUND 
COLOUR  element  or  the  the  colour  Index  0.  For  direct  colour  selection,  either  the  background  colour  or  the 
colour  of  each  displayed  primitvie  shall  be  explicitly  specified,  or  none  shall  be  specified.  In  other  words,  either 
ail  colours  shall  t>e  defaulted  or  none  shall  be  defaulted. 

12.         The  maximum  number  of  colour  values  that  can  appear  in  the  Colour  List  parameter  for  the  COLOUR  TABLE 
element  is  64.  This  will  support  a  63  entry  colour  table. 

B.4     Interoperability  with  SGML  applications 

The  recommended  method  for  the  exchange  of  documents  between  Standard  Generalized  Markup 
Language  (ISO  8879,  SGML)  based  systems  and  systems  based  on  this  ODA  document  application  profiie 
Is  by  means  of  exchanging  a  document  representation  conforming  to  these  agreements  in  an  encoded  form 
of  the  SGML  language  known  as  the  Office  Document  Language  (ODL).  ODL  is  a  standardized  SGML 
application  for  representing  documents  conforming  to  the  ODA  t>ase  standard.  Such  a  representation  can 
be  converted  into  the  Office  Document  Interchange  Format  (ODIF)  supported  by  this  document  application 
profile. 
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Annex  C  (informative) 

References  to  other  standards  and  registers 

[I]  CCITT  Recommendation  T.400  :  1988,  Introduction  to  Document  Architecture,  Transfer  and 
Manipulation; 

[2]       CX5ITT  Recommendation  T.41 1 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Introduction  and  General  Principles; 

[3]       CCITT  Recommendation  T.41 2 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Fomnat: 
Document  Structures; 

[4]       CCITT  Recommendation  T.41 4 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Profile; 

[5]       CCITT  Recommendation  T.41 5 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Open  Document  Interchange  Format; 

[6]       CCITT  Recommendation  T.41 6 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  FonDat: 
Character  Content  Architecture; 

[7]       CCITT  Recommendation  T.41 7 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Raster  Graphics  Content  Architecture; 

[8]       CCITT  Recommendation  T.41 8 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Geometric  Graphics  Content  Architecture; 

[9]       CCITT  Recommendation  T.502  :  1990,  Document  Application  Profile  PM-1 1  for  the  Interchange  of 
Character  Content  Documents  in  Processable  and  Formatted  Forms; 

[10]     CCITT  Recommendation  T.503  :  1984,  Document  Application  Profile  for  the  Interchange  of  Group 
4  Facsimile  Documents; 

[II]  CCITT  Recommendation  T.505  :  1990,  Document  Application  Profile  PM-26  for  the  Interchange  of 
Enhanced  Mixed  Content  Documents  in  Processable  and  Formatted  Forms; 

[12]     ISO  8571  :  1988,  Information  processing  systems  -  Open  Systems  Interconnection  -  File  transfer, 
access  and  management; 

[13]     ISO  9070  :  1990,  Information  processing  -  SGML  support  facilities  -  Registration  procedures  for 
public  owner  identifiers; 

[14]     ISO/TR  9573  : 1988,  Information  processing  -  SGML  technical  report  -  Techniques  for  using  SGML; 

[15]     ISO  10021  :  (to  be  published).  Information  processing  systems  -  Text  communication  -  Message 
Oriented  Text  Interchange  System; 
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[16]     ISP  F0D1 1  :  (to  be  published),  Office  document  format  profile  for  the  interchange  of  basic  function 
character  content  document  in  processable  and  formatted  forms; 

[17]      ISP  FOD26  :  (to  be  published),  Office  document  format  profile  for  the  interchange  of  enhanced 
function  mixed  content  documents  In  processable  and  formatted  forms; 

[18]     ISP  FOD36  :  (to  be  published).  Office  document  format  profile  for  the  interchange  of  extended 
function  mixed  content  documents  in  processable  and  formatted  forms; 

[19]      MIL-R-28002A  :  1990,  MILITARY  SPECIFICATION,  RASTER  GRAPHICS  REPRESENTATION  IN 
BINARY  FORMAT.  REQUIREMENTS  FOR. 
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Annex  D  (informative) 

Supplementary  information  on  attributes 


Table  D.I  Content  coding  attributes 


AttributM 

Basic  values 

Default  values 

Non-basic 
values 

N  umber-of-pels-per-line 

any  positive  integer 

None 

None 

Number-of-lines 

any  positive  integer 

None 

None 

Tiling-offset* 

(any  non-negative  integer 
<  512,  any  non-negative 
integer  <  512) 

(0,0) 

None 

Tile-types* 

T.6  encoded,  bitmap 
encx>ded,  null 
background,  null 
foreground,  T.6  encoded  - 
MSB 

T.6  encoded 

None 

Type-of-coding 

T.6  encoding  (untiled), 
bitmap  (untiled),  tiled 
encoded,  T.4  ID 
encoding,  T.4  2D 
encoding,  T.6  encoding  - 
MSB  (untiled),  T.4  ID 
encoding  -  MSB,  T.4  2D 
encoding  -  MSB 

T.6  encoding,  T.6 
encoding  -  MSB,  tiled 
encoding  ** 

None 

Tutorial  Note  -  *  Only  used  if  type  of  coding*  is  'tiled  encoded' 


Tutorial  Note  -  **  As  specified  in  the  document  profile 


Table  D.2  Presentation  attributes 


Attributes 

Basic  values 

Default  values 

Non-basic  values 

Pel-path 

0,  90  deg 

0  deg 

180,  270  deg 

Line-progression 

270  deg 

270  deg 

90  deg 

Pel-spacing 

16,  12.  8,  6,  5,  4,  3,  2,  1 
BMU 

4  BMU  (300) 

Any  value  except 
'null- 

Clipping 

Two  Coordinate  Pairs 
(any  non-negative  integer, 
any  non-negative  integer) 

(0,0),  (N-1.  L-1) 

None 

54 


PART  22  -  ODA  Image  DAP  Docembor  1992  (Stable) 


Table  D.3  Document  profile  attributes 


Attribute 

Class 

Permissible  values 

Specific-layout-structure 

m 

present 

Presentation-styles 

nm 

present 

Document-characteristics 

M 

Document-architecture-class 

m 

formatted 

uocumern-appiicanon-proTiie 

m 

{-  See  clause  8  for  a  definition  of  the 
permitted  values  for  this  attribute.  -} 

uomeni-arcniiecture-ciasses 

m 

{2  8  2  7  2},  {2  8  2  8  0},  {2  8  2  6  0} 

Interchange-format-class 

m 

A 

ODA-version 

m 

ISO  8613,  1991-12-31 

Document-architecture-defaults 

M 

Content-architecture-class 

m 

formatted  processable  raster  gr£\phics 

Type-of-coding 

m 

T.6  encoding,  tiled  encoding,  T.6 
encoding  -  MSB 

Page-dimensions 

nm 

See  list  in  table  1 ,  (Default  value  is  NA- 
A,  9240  X  13200  BMU) 

Medium-types 

nm 

See  list  in  table  1 ,  (Default  value  is  NA- 

A,  9240  X  1o2UU  dMU) 

Page- position 

nm 

any  coordinate  pair  within  page 

Raster-gr-content-defaults 

Pel-path 

nm 

0,  90,  180,  270  degrees  (0  is  normal 
default) 

Line-progression 

nm 

90,  270  degrees  (270  is  normal  default) 

Pel-spacing 

nm 

16,  12,  8,  6,  5,  4,  3,  2,  or  1  BMU 
(Normal  default  is  4  BMU) 

Spacing  Ratio 

nm 

Any  value 

Non-basic-doc-characteristics 

NM 

Page-dimensions 

nm 

See  table  1 

Medium-types 

nm 

See  table  1 
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Table  D.3  Document  profile  attributes  (concluded) 


Attribute 

Class 

Permissible  values 

Raster-gr-presentation-features 

NM 

Pel-path 

nm 

180,  270  degrees 

Line-progression 

nm 

90  degrees 

Pel-spacing 

nm 

16,  12,  8,  6,  5.  4,  3.  2,  or  1  BMU 

Document-nnanagement-attributes 

M 

Document  Reference 

m 

Any  string  of  characters 

The  following  notation  is  used  in  the  class  column  of  this  table: 

a)  m   nnandatory  attribute 

b)  nm  non-mandatory  attribute 

c)  d  defaultabie  attribute 

Capital  letters  (M,  NM,  and  D)  are  used  for  groups  of  attributes. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture  (ODA) 
Special  Interest  Group  (SIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 
Development  of  this  document  application  profile  has  been  done  in  liaison  with  several  organizations.  These 
include  the  DoD  Computer-aided  Acquisition  and  Logistic  Support  (GALS)  Office,  Navy's  David  Taylor 
Research  Center,  and  the  ad-hoc  Tiling  Task  Group. 

This  document  application  profile  is  intended  to  be  suitable  for  the  interchange  of  large  format  raster  images. 
This  part  contains  four  annexes: 

a)  annex  A  (normative):  Amendments  and  corrigenda; 

b)  annex  B  (informative):  Recommended  practices; 

c)  annex  C  (informative):  References  to  other  standards  and  registers; 

d)  annex  D  (informative):  Supplementary  information  on  attributes. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part.  Deleted  and  replaced  text  will  be  shown  as  struckout.  New  and  replacement  text  will  be  shown  as 
shaded. 

This  part  uses  a  convention  of  double  and  single  quotes  that  has  been  established  by  ISO  for  use  in  the 
ODA  base  standard  and  related  document  application  profiles.  The  convention  is  to  use  within  the  text 
double  quotes  to  accentuate  ODA  attribute  names  and  single  quotes  to  accentuate  values  for  those 
attributes. 
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Part  23  -  ODA  Raster  DAP 


0  Introduction 

This  is  the  definition  of  a  specification  for  an  Open  Document  Architecture  (ODA)  Document  Application 
Profile  (DAP)  named  ODA  Raster  DAP.  This  DAP  is  suitalale  for  interchanging  documents  in  formatted  form. 
The  documents  contain  only  raster  graphics  images. 

There  are  two  DAP  object  Identifiers  supporting  this  DAP  with  the  only  difference  being  in  the  encoding  of 
the  data  stream.  One  uses  the  ASN.l  based  ODIF  encoding.  The  other  uses  the  SGML/SDIF  based  ODL 
encoding.  When  this  document  refers  to  this  profile,  it  is  referring  to  this  specification  regardless  of  which 
DAP  identifier  may  be  selected  to  create  the  data  stream. 

This  DAP  has  been  prepared  by  the  ODA  Special  Interest  Group  (SiG)  of  the  Open  Systems  Environment 
Implementors'  Workshop  (OIV\0.  The  DAP  is  defined  in  accordance  with  ISO  8613-1  and  follows  the 
standardized  proforma  and  notation  defined  in  ISO  8613-1  Annex  F.  The  DAP  is  based  on  ODA  as  defined 
In  ISO  8613  and  the  Tiled  Raster  Graphics  Addendum  to  ISO  8613,  Part  7. 


1     Scope  and  field  of  applications 

This  DAP  specifies  an  interchange  format  suitable  for  transfer  of  structured  documents  between  equipment 
designed  for  raster  processing.  The  documents  supported  by  this  DAP  are  based  on  a  paradigm  of  an 
electronic  engineering  drawing  or  illustration.  Such  documents  contain  one  or  more  pages.  Each  page 
consists  of  an  Image  In  the  form  of  a  bi-tonal  raster  graphics  content.  There  Is  no  restriction  on  the 
minimum  size  of  the  image. 

This  document  defines  a  DAP  that  allows  large  format  raster  documents  to  be  interchanged  in  a  formatted 
form  In  accordance  with  ISO  8613. 

It  Is  assumed  that,  when  negotiation  is  performed  by  the  service  using  this  DAP,  all  non-basic  values  are 
subject  to  negotiation. 

This  DAP  Is  independent  of  the  processes  carried  out  in  an  end  system  to  create,  edit,  or  reproduce  raster 
documents.  It  is  also  independent  of  the  means  to  transfer  the  document  which,  for  example,  may  be  by 
means  of  communication  linl<s  or  exchanged  storage  media. 

The  features  of  a  document  that  can  be  interchanged  using  this  DAP  fall  into  the  following  categories: 

a)  Page  format  features  -  these  concern  how  the  layout  of  each  page  of  a  document  will  appear 
when  reproduced; 

b)  Raster  graphics  layout  and  imaging  features  -  these  concern  how  the  document  content  will 
appear  within  pages  of  the  reproduced  document; 

c)  Raster  graphics  coding  -  these  concern  the  raster  graphics  representations  and  control 
functions  that  mal<e  up  the  document  raster  graphics  content. 
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2     Normative  references 

The  following  references  are  required  In  order  to  Implement  this  DAP: 


2.1  ISO 

[I]  ISO  8613-1  : 1989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  1:  Introduction  and  General  Principles; 

[2]  ISO  861 3-2  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  2:  Document  Structures; 

[3]  ISO  861 3-4 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  4:  Document  Profile; 

[4]  ISO  861 3-5  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  5:  Open  Document  Interchange  Format; 

[5]  ISO  861 3-7 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  7:  Raster  Graphics  Content  Architectures; 

[6]  ISO  861 3-1  : 1 991 ,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  1:Annex  F  -  A  Document  Application  Profile  Proforma  and 
Notation; 

[7]  ISO  861 3-7 :  (to  be  published),  Information  processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  -  Part  7:  Amendment  -  Tiled  Raster  Graphics  Addendum 
to  ISO  8613,  Part  7; 

[8]  ISO  8613-7 :  (to  be  published),  Information  processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  -  Part  7:  Amendment  -  Additional  Bit  Order  Mapping 
Addendum; 

[9]  ISO  8824  :  1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Abstract  Syntax  Notation  One  (ASN.  1); 

[10]  ISO  8825  :  1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.  1); 

[II]  ISO  8879  : 1 986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML); 

[12]  ISO  8879  :  1986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML),  Amendment  1; 

[13]  ISO  9069  : 1988,  Information  processing  -  SGML  support  facilities  -  SGML  Document  Interchange 
Format  (SDIF). 
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2.2  CCITT 

[14]     Recommendation  T.4  :  1988,  Standardization  of  Group  3  Facsimile  Apparatus  for  Document 
Transmission. 

[15]     Recommendation  T.6  : 1 988.  Facsimile  Coding  Sctiemes  and  Coding  Control  Functions  for  Group 
4  Facsimile  Apparatus. 


3    Definitions  and  terminology 


3.1  Definitions 

The  definitions  given  in  ISO  8613-1  are  applicable  to  this  document. 


3.2      Constituent  names 

Each  constituent  that  may  be  included  in  a  document  that  conforms  to  this  profile  has  t>een  given  a  unique 
name  which  serves  to  identify  that  constituent  throughout  this  profile. 

The  convention  is  that  full  names  are  used  (i.e.,  no  abbreviations  are  used),  two  or  more  words  in  a  name 
are  concatenated  and  each  word  begins  with  a  capital.  Examples  of  constituent  names  used  in  this  profile 
are  CompositePage,  DocumentLayoutRoot,  and  SpecificBlock. 

In  clause  6,  each  constituent  provided  by  this  profile  is  underlined  once  at  the  point  In  the  text  at  which  the 
purpose  of  that  constituent  is  defined.  This  also  serves  to  identify  all  the  constituents  provided  by  this 
profile. 

The  same  constituent  names  are  also  used  in  the  technical  specification  in  clause  7  so  that  there  is  a 
one-to-one  correspondence  between  the  use  of  these  names  in  clauses  6  and  7. 

Although  the  constituent  names  relate  to  the  purpose  of  the  constituents,  the  semantics  of  constituents  must 
not  be  implied  from  the  actual  names  that  are  used.  Also,  these  names  do  not  appear  in  an  interchanged 
document  but  a  mechanism  for  identifying  constituents  in  an  interchange  document  is  provided.  Thus  in 
an  application  using  this  profile,  the  constituents  may  be  known  to  the  user  by  different  names. 
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Functionally,  this  DAP  is  a  functional  superset  of  the  CCITT  Recommendation  T.503,  A  Document  Application 
ProfHe  for  the  Interchange  of  Group  4  Facsimile  Documents.  This  DAP  is  a  functional  subset  of  Part  22  - 
ODA  image  DAP. 


5  Conformance 

In  order  to  conform  to  this  DAP,  a  data  stream  representing  a  document  must  meet  the  requirements 
specified  in  5.1. 

The  requirements  for  implementations  that  originate  and /or  receive  data  streams  conforming  to  this  DAP 
are  specified  in  5.2. 


5.1      Data  stream  conformance 

The  following  requirements  apply  to  the  encoding  of  data  streams  that  conform  to  these  agreements: 

a)  The  data  stream  shall  be  encoded  in  accordance  with  the  ASN.1  encoding  rules  defined  In 
ISO  8825  or  the  SGML  grammar  and  syntax  of  ISO  8879; 

b)  The  data  stream  shall  be  structured  in  accordance  with  the  interchange  format  defined  in 
clause  8; 

c)  The  document  shall  be  structured  in  accordance  with  only  the  formatted  document 
architecture  class  specified  in  clause  7.  In  addition,  the  document  shall  contain  all  mandatory 
constituents  specified  for  that  class  and  may  optionally  contain  constituents  permitted  for  that 
class  as  specified  in  clause  7; 

d)  Each  constituent  shall  contain  all  those  attributes  specified  as  required  for  that  constituent  in 
this  profile.  Other  attributes  may  be  specified  provided  they  are  permitted  for  that  constituent; 

e)  The  attributes  shall  have  values  within  the  range  of  permissible  values  specified  In  this  profile; 

f)  The  encoded  document  shall  be  structured  in  accordance  with  the  abstract  document 
architecture  defined  in  ISO  8613-2; 

g)  The  encoded  document  shall  be  structured  in  accordance  with  the  characteristics  defined  In 
clause  6  and  shall  contain  only  those  features  defined  in  clause  6. 
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5.2      Implementation  conformance 

This  clause  states  the  requirements  for  implementations  claiming  conformance  to  this  DAP. 

A  conforming  receiving  implementation  must  t>e  capable  of  receiving  either  any  data  streams  conforming 
to  this  profile  structured  in  accordance  with  ODIF  or  any  data  streams  conforming  to  this  profile  stmctured 
in  accordance  with  ODL  or  Ixjth  of  these.  Receiving  usually,  but  not  always,  involves  recognizing  and 
further  processing  the  data  stream  elements. 


6    Characteristics  supported  by  this  DAP 

This  clause  describes  the  characteristics  of  docunfients  that  can  be  represented  by  data  streams  conforming 
to  this  profile.  This  clause  also  describes  how  these  characteristics  are  represented  in  temris  of  divisional 
components  of  the  data  streams. 


6.1  Overview 

This  DAP  describes  the  features  of  ISO  8613  that  are  needed  to  support  the  interchange  of  documents 
containing  only  raster  graphics  content,  it  specifies  interchange  formats  for  the  transfer  of  structured 
documents  with  simple  layout  structures. 

This  DAP  describes  documents  that  can  be  interchanged  in  the  formatted  form,  which  facilitates  the 
reproduction  of  a  document  as  intended  by  the  originator. 

Only  one  category  of  content  is  allowed  within  the  document,  that  is,  a  raster  graphics  content  in  the 
formatted  processable  form.  This  is  intended  to  facilitate  the  reproduction  of  the  document  content  as 
intended  by  the  originator. 

This  clause  describes  the  layout  features  that  can  be  represented  in  documents  conforming  to  this  DAP. 
The  features  are  described  in  terms  that  are  typical  of  the  user-perceived  capabilities  and  semantics  found 
in  a  raster  document  interchange  environment. 

For  the  purpose  of  interchange,  a  document  is  represented  as  a  collection  of  constituents,  each  of  which 
is  represented  by  a  set  of  attributes.  The  constituents  that  make  up  a  formatted  document  are  defined 
below  in  this  clause  and  are  illustrated  in  figure  1. 

Constituents  defined  as  required  must  occur  in  any  document  that  conforms  to  this  profile.  Constituents 
listed  as  optional  may  or  may  not  be  present  in  the  document,  depending  on  the  requirements  of  the 
particular  document. 

The  required  constituents  include: 

a)  a  document  profile; 

b)  layout  object  descriptions  representing  a  specific  layout  structure; 
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Document  Profile 


Presentation  Style 
(Optional) 


Specific  Layout 
Structure 


Content  Portion 
Description 


Figure  1  -  Constituents 


6.2      Logical  constituents 

Not  applicable. 


6.3      Layout  constituents 

This  clause  descrlt)es  the  features  of  the  layout  objects  that  can  be  represented  in  documents  conforming 
to  this  DAP. 


6.3.1       Overview  of  the  layout  characteristics 

The  document  structure  allows  the  document  content  to  be  laid  out  and  presented  in  one  or  more  pages. 
Each  page  in  a  document  consists  of  only  a  single  raster  graphics  content  representing  an  engineering 
drawing,  illustration,  or  other  raster  scanned  image. 

A  specific  layout  structure  of  the  document  conforming  to  this  application  profile  consists  of  a  four-level 
hierarchy  consisting  of  a  document  layout  root,  composite  pages,  frames,  and  blocks.  The  document  can 
consist  of  multiple  composite  pages  where  each  page  represents  a  single  image.  Each  composite  page 
consists  of  a  frame  which  in  turn  contains  a  block  containing  the  content  associated  with  the  image. 

Figure  2  is  an  illustration  of  the  features  of  the  document  layout  structure  supported  by  this  DAP. 


6.3.2  DocumentLayoutRoot 

A  DocumentLayoutRoot  is  the  top  level  in  a  document  layout  structure.  A  DocumentLayoutRoot  consists 
of  a  sequence  of  one  or  more  CompositePage  constituent  constraints. 
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Figure  2  -  Document  layout  structure 


6.3.3       Page  characteristics 

Only  one  constituent  constraint  is  provided  to  present  pages  witliin  a  document. 


A  document  consists  of  a  sequence  of  one  or  more  composite  pages.  In  a  document's  composite  page, 
a  frame  Is  used  to  position  a  single  raster  graphics  content  representing  the  image  on  the  page. 

A  document  may  consist  of  multiple  pages  of  different  sizes.  Each  page  may  be  either  landscape  or  portrait 
orientation.  Both  orientations  are  permitted  in  the  document. 


6.3.3.1  CompositePage 

A  CompositePage  is  a  constituent  constraint  which  defines  a  composite  page  that  corresponds  to  the  page 
area  used  for  presenting  the  sequence  of  an  InnageFrame  frame. 


6.3.3.2        Page  dimensions 

A  wide  variety  of  page  dimensions  are  supported  including  large  format  raster  documents.  The  dimensions 
of  the  pages  may  be  specified  as  any  value,  in  BMU  measurement  units,  including  the  larger  sizes  produced 
from  foldout-size  Images  and  roll  paper.  These  sizes  apply  to  both  portrait  and  landscape  orientations.  The 
page  sizes  include:  ISO  A0-A5,  ANSI  A-K,  Japanese  legal  and  letter,  fddouts  27.94  cm  (1 1  in.)  X  35.56  cm 
(14  in.)  and  27.94  cm  (11  in.)  X  43.18  cm  (17  in.),  and  27.94  cm  (11  in.)  roll  paper.  See  table  1. 

Dimensions  equivalent  to  or  less  than  the  common  assured  reproduction  area  (CARA)  of  ISO  A4  and  North 
American  Letter  (NAL)  in  portrait  or  landscape  orientation  are  basic  values.  Larger  page  sizes  including 
those  produced  from  roll  paper  are  non-basic  and  their  use  must  be  indicated  in  the  document  profile  (See 
table  2). 

The  default  dimensions  are  the  CARA  of  North  American  Letter  (A).  Any  default  page  dimensions  may  be 
specified  in  the  document  profile  subject  to  the  maximum  dimensions  defined  above  by  using  the  "page 
dimensions"  attribute.  The  "page  position"  attribute  may  be  used  to  specify  the  position  of  the  pel  array 
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image  on  the  page.  Although  actual  page  dimensions  may  be  used  allowing  for  the  raster  content  to 
completely  fill  a  page  leaving  no  borders,  it  is  advised  that  the  assured  reproduction  area  (ARA)  listed  in 
table  1  t>e  used  wherever  feasible.  See  7.3  of  ISO  8613-2  for  general  rules  for  positioning  pages  on 
presentation  surfaces. 


6.3.3.3        Nominal  page  sizes 

The  nominal  page  sizes  that  may  be  specified  are  listed  in  tat>le  1 .  In  addition,  1 1  inch  roil  paper  of  any 
length  is  supported.  These  may  be  specified  in  portrait  or  landscape  orientations.  All  values  of  nominal 
page  size  are  non-basic  and  hence  all  values  used  in  a  document  must  be  indicated  in  the  document  profile 
using  the  'medium  type"  attribute  (See  table  2). 

Any  of  the  nominal  page  sizes  defined  in  table  1 ,  subject  to  the  restriction  specified  above,  may  be  specified 
as  the  default  value  in  the  document  profile. 

Table  1  also  includes  the  recommended  ARA.  Information  loss  may  occur  when  a  document  is  reproduced 
if  the  dimensions  of  the  CompositePage  exceed  the  ARA  for  the  specified  nominal  page  size. 


6.3.4  ImageFrame 

An  ImageFrame  is  a  constituent  constraint  which  defines  a  lowest  level  frame  used  for  laying  out  the  image 
of  an  engineering  drawing,  illustration,  or  other  raster  scanned  image.  This  frame  contains  a  single 
SpecificBlock  containing  a  raster  graphics  content  portion.  Note  that  there  must  be  exactly  one 
ImageFrame  on  each  page  and  one  t>lock  in  the  frame. 

The  frame  has  a  fixed  position  that  is  equal  to  the  origin  of  the  page.  The  vertical  and  horizontal  dimensions 
of  this  frame  are  fixed  and  equal  to  the  maximum  size  that  can  be  achieved  for  the  position  within  the  area 
of  the  page. 


6.3.5  SpecificBlock 

A  SpecificBlocl<  is  a  constituent  constraint  which  defines  a  basic  layout  object  used  to  position  and  image 
the  content  portions  associated  with  an  ImageFrame. 

The  position  of  the  block  is  fixed  and  defaults  to  the  origin  of  the  superior  frame.  The  dimensions  default 
to  the  maximum  size  that  can  be  achieved  for  the  position  within  the  area  of  the  superior  frame. 
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Dimensions  for  various  page  sizes 


Pag*  type 

Size 

Size  (BMU) 

ARA  (BMU) 

-  Metric 

ISaA5 

148mm  X  210mm 

7015  X  9920 

not  defined 

IS0-A4 

210mm  X  297mm 

9920  X  14030 

9240  X  13200 

IS0-A3 

297mm  x  420mm 

14030  X 19840 

13200  X  18480 

IS0-A2 

420mm  x  594mm 

19840  x  28060 

18898x27118 

IS0-A1 

594mm  x  841  mm 

28060  x  39680 

26173  X  37843 

ISO-AO 

841mm  X  1189mm 

39680  X  56120 

37843  X  54283 

-  ANSI,  North  American  (NA) 

NA-A 

8.5in  X  Ilin 

10200  X 13200 

9240  X  12400 

NA-B 

Ilin  X  17in 

13200  X  20400 

12744  X  19656 

NA-C 

17in  X  22in 

20400  x  26400 

19500  X  25800 

NA-D 

22in  X  34in 

26400  x  40800 

25800  x  39600 

NA-E 

34in  X  44in 

40800  x  52800 

39600  X  52200 

NA-F 

28in  X  40in 

33600  x  48000 

32400  X  47400 

NA-G 

1 1  in  X  90in 

13200  X  108000 

12400  X  106800 

NA-H 

28in  X  143in 

33600  X  171600 

31400  X  170400 

NA-J 

34in  X  176in 

40800x211200 

39600  x  210000 

NA-K 

40in  X  143in 

48000  X 171600 

47400  X  170400 

NA-Legal 

8.5in  X  14in 

10200  X  16800 

9240  X  15480 

-  Foldouts 

Small 

Ilin  X  14in 

13200  X  16800 

12744  X  15480 

NA-B 

Ilin  X  17in 

13200  X  20400 

12744  X  19656 

-  Japan 

Legal 

257mm  x  364mm 

12141  X 17196 

11200  X  15300 

Letter 

182mm  X  257mm 

8598  X 12141 

7600  X  10200 

Tutorial  Note  -  These  page  sizes  are  for  the  portrait  orientation. 
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Table  2  -  Layout  attributes 


Attributes 

Basic  values 

Default 
values 

Non-basic 
values 

Page  dimensions  ** 

CARA  NA  A, 
ISO  A4 

CARA  NA-A 

ARA  NA  B-K, 
ISO  A0-A3,Japan 
legal, 

11'  Roll  Paper 

Medium-type  ** 
(Nominal  page  size) 

None 

None 

NA  A-K, 
ISO  A0-A5, 
Japan  letter  & 
legal, 

ir  Roll  Paper 

Tutorial  Note  -  See  table  1 


6.4      Document  layout  characteristics 

This  DAP  provides  only  for  formatted  documents.  Hence,  no  provision  is  made  for  constraining  tiie 
document  layout  process  other  than  as  implied  in  the  formatted  documents  supported  by  this  DAP.  In 
particular,  these  formatted  documents  are  characterized  by  the  following: 

a)  Documents  containing  only  composite  pages; 

b)  Documents  may  contain  one  or  more  pages; 

c)  Pages  may  vary  by  orientation  within  a  document; 

d)  Each  page  contains  a  single  raster  graphics  content  portion  representing  the  image; 

e)  Content  is  positioned  within  fixed  position  and  dimension  frames. 


6.5      Content  layout  and  imaging  control 

A  document  is  modelled  as  an  image  represented  by  a  raster  graphics  content  portion,  as  specified  in  ISO 
8613-7. 

The  only  content  architecture  that  may  be  specified  using  the  attribute  "content  architecture  class"  is 
formatted  processable  raster  graphics.  The  formatted  processable  raster  graphics  content  must  be  specified 
as  the  default  in  the  document  profile. 
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6.5.1 


Raster  graphics  content 


6.5.1.1 


Introduction 


This  clause  defines  the  features  that  are  applicable  to  the  raster  graphics  content. 
The  default  values  for  the  following  features  niay  be  specified  In  the  document  profile: 

a)  type  of  coding  (required); 

b)  compression; 

c)  pel  path; 

d)  line  progression; 

e)  pel  spacing; 

f)  spacing  ratio. 

The  specification  in  a  document  of  a  non-basic  value  by  a  presentation  or  coding  attribute  must  be  indicated 
in  the  document  profile. 


6.5.1.2        Raster  graphics  content  architecture 

The  formatted  processable  raster  graphics  content  is  the  only  content  architecture  class  supported  by  this 
DAP  and  is  the  only  default  content  architecture  class  that  can  be  specified  in  the  document  profile. 

In  a  composite  page,  only  one  content  portion  can  be  associated  with  the  image. 


6.5.1.3        Raster  graphics  encoding  methods 

The  content  may  be  encoded  in  accordance  with  the  encoding  schemes  defined  in  CCITT 
Recommendations  T.4  and  T.6.  In  the  case  of  T.4,  either  the  one-dimensional  or  two-dimensional  encoding 
scheme  may  be  used.  Also  the  bitmap  encoding  scheme  defined  in  ISO  8613-7  may  be  used.  Ail  these 
forms  of  encoding  may  be  used  in  a  single  document  and  all  are  basic  values.  'Uncompressed'  mode  of 
encoding  may  also  be  used  but  only  as  a  non-basic  value. 

In  a  content  portion,  it  is  required  that  the  coding  attribute  "number  of  pels  per  line"  be  specified.  The 
coding  attribute  "number  of  lines"  may  also  be  specified.  No  restriction  is  placed  on  the  values  that  may 
be  specified  for  these  coding  attributes.  This  profile  places  no  constraints  on  the  size  of  the  pel  arrays  that 
may  be  used. 

The  type  of  coding  method  used  is  specified  by  the  attribute  "type  of  coding".  The  use  of  this  attribute  Is 
mandatory  in  the  "document  architecture  defaults"  of  the  document  profile  to  define  the  default  value  of 
either  T.6  encoding'  (untiled),  T.6  encoding  -  MSB'  (untiled),  or  'tiled  encoding'.  The  use  of  this  attribute 
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in  the  description  of  tlie  content  portions  is  non-nnandatory.  If  this  attribute  is  not  specified  for  a  particular 
content  portion,  tlien  the  default  value  specified  in  the  "document  architecture  de^uits'  of  the  document 
profile  is  used. 

if  the  tiled  encoding  method  is  used,  the  default  value  of  512  for  the  "number  of  pels  per  tile  line"  and 
"number  of  lines  per  tile"  must  be  used.  No  other  values  are  supported,  therefore  these  two  attributes  do 
not  need  to  t>e  specified.  If  the  "tile  types"  attribute  is  not  present,  then  ail  tiles  will  be  T.6  encoded.  If  it  Is 
present,  then  there  must  be  a  value  specified  for  each  tile  in  which  case  only  'null  background',  'null 
foreground',  'T.6  encoded',  'T.6  encoded  -  MSB',  or  'bitmap  encoded'  values  are  supported.  The  T.4 
encodings  are  not  supported.  There  are  no  restrictions  on  the  use  of  the  "tiling  offset"  attribute  other  than 
that  specified  in  ISO  8613-7  Addendum. 

See  table  D.I,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-basic  values. 


6.5.1 .4        Raster  presentation 

Raster  presentation  is  controlled  by  the  presentation  attributes  specified  in  ISO  8613-7.  This  DAP  provides 
for  additional  constraints  on  these  presentation  attributes  as  specified  below. 

The  basic  values  for  the  attribute  "pel  path"  supported  by  this  profile  are  0  and  90  degrees.  The  "pel  path" 
values  of  180  and  270  degrees  are  non-basic. 

The  basic  values  for  the  attribute  "line  progression"  supported  by  this  profile  is  270  degrees.  The  "line 
progression"  value  of  90  degrees  is  non-basic. 

Any  value  may  be  explicitly  specified  for  pel  spacing  provided  that  the  spacing  between  pels  is  not  less  than 
1  BMU.  The  pel  spacing  need  not  be  an  integer  value.  The  value  of  'null'  may  not  be  specified  because 
the  scalable  layout  process  is  not  supported.  The  specification  of  the  spacings  of  16,  12,  8,  6,  5,  4,  3,  2, 
and  1  BMU  between  adjacent  pels  are  basic.  The  specification  of  any  other  spacing  is  non-basic  and  must 
be  specified  in  the  document  profile. 

NOTES 

1  The  basic  pel  spacing  values  listed  above  are  equivalent  to  resolutions  of  75,  100,  150,  200,  240,  300,  400, 
600,  and  1200  pels  per  25.4mm  respectively  when  the  BMU  is  interpreted  as  1/1200  inch. 

2  The  attribute  "pel  spacing"  specifies  two  integers,  the  ratio  of  which  determines  the  pel  spacing.  No 
restriction  is  placed  on  the  values  of  these  integers. 

There  are  no  restrictions  on  the  use  of  the  "clipping"  attribute.  The  "image  dimensions"  attribute  is  not 
supported. 

There  are  no  restrictions  placed  on  the  value  of  the  "spacing  ratio"  attribute  providing  tfiat  the  resultant  line 
spacing  is  not  less  than  1  BMU.  Also,  the  line  spacing  need  not  be  an  integral  number  of  BMUs.  All  values 
are  basic. 

See  table  D.2,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-t)asic  values. 
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6.6  Miscellaneous  features 

Specification  of  tfie  attribute  "application  comments"  is  optional.  When  used  in  conjunction  with  the  type 
of  coding"  of  'tiled  encoding',  it  contains  a  sequence  of  positive  integers,  one  for  each  tile  in  the  content 
portion.  The  sequence  of  integers  is  a  set  of  indices  representing  the  octet  offsets  to  the  beginning  of  the 
respective  tiles,  starting  from  the  beginning  of  the  "content  information".  A  tile  index  of  zero(0)  indicates  that 
the  respective  tHe  is  null.  The  integers  will  be  sequenced  In  the  same  order  as  the  tiles.  The  tiles  will  be 
sequenced  prin^rily  in  the  pel  path  and  secondarily  in  the  line  progression  direction  as  defined  by  the 
presentation  attributes. 

6.7  Document  management  features 

Every  document  interchanged  in  accordance  with  this  DAP  must  Include  a  document  profile  containing 
information  which  relates  to  the  document  as  a  whole. 

The  features  specified  by  the  document  profile  are  listed  below.  A  definition  of  the  Information  contained 
in  these  features  is  given  in  the  corresponding  attribute  definitions  in  ISO  8613-4. 

Document  constituent  information: 

a)  specific  layout  structure; 

b)  presentation  styles  (optional). 
Document  characteristics: 

a)  document  application  profile; 

b)  document  application  profile  defaults; 

c)  document  architecture  class; 

d)  content  architecture  class; 

e)  interchange  format  class; 

f)  ODA  version  date; 

g)  raster  graphics  content  defaults. 


Non-basic 


document  characteristics: 


a) 


page  dimensions; 


b) 


medium  type; 


c) 


raster  graphics  presentation  features. 
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Document  management  attributes: 

a)  document  description  (only  document  reference  supported). 
Tlie  attributes  applicable  to  the  document  profile  are  defined  in  table  D.3.  Annex  D. 


7     Specification  of  constituent  constraints 


7.1      Document  profile  constraints 


7.1.1       Macro  definitions 

-  General  macros  - 
DEFINE(FDA,  "{'formatted'}") 

DEFINE(DAC,  "DocumentProfile  (Document-arcfiitecture-class)") 

DEFINE(FPR,''ASN.1{2  8  2  7  2}")     Raster  fornfiatted  processable  -- 

--  Basic  page  dimensions.  - 
DEFINE(BasicPageDimension," 

REQ  #horizontal-dimension  {REQ  #fixed-dimension  {  1..9240  }}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {  1.. 12400  }} 
I  REQ  #liori2ontal-dimension  {REQ  #fixed-dimension  {  1.. 12400  }}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {  1..9240  }} 
■') 

-  Any  size  equal  to  or  smaller  than  CARA  (Common  Assured  Reproduction  Area)  of  ISO  A4  and  NA  A.  Both 
Portrait  and  Landscape  may  be  specified.  -- 

-  Non-basic  page  dimensions.  - 
DEFINE(NonBasicPageDimensions," 

{REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 39680}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {12401. .56120}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {9241  ..39680}}, 
REQ  #vertical-dimension  {REQ  #flxed-dimension  {1.. 56120}}} 

-  up  to  ISO  AO  portrait  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 56120}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {9241. .39680}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {12401. .561 20}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 39680}}} 

--  up  to  ISO  AO  landscape  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 48000}}, 
REQ  #verticai-dimension  {REQ  #fixed-dimension  {12401. .21 1200}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {9241. .48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 21 1200}}} 
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-  up  to  ANSI  J/K  portrait  - 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dlmension  {1. 21 1200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimenslon  {9241. .48000}}} 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dlmension  {12401. .21 1200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimenslon  {1.. 48000}}} 

up  to  ANSI  J/K  larxiscape  - 
I  {REQ  #horizontal-dlmension  {REQ  #fixed-dimenslon  {1..12141}}, 
REQ  #vertical-climension  {REQ  #fixed-dlmension  {12401. .17196}}} 
I  {REQ  #horlzontal-dlmenslon  {REQ  #flxed-dimension  {9241. .12141}}. 
REQ  #vertical-climension  {REQ  #fixed-dimension  {1..17196}}} 

up  to  Japanese  legal  portrait  - 
I  {REQ  #horizontal-climension  {REQ  #flxed-dlmenslon  {1.. 17196}}, 
REQ  #vertical-dlmension  {REQ  #fixed-dimenslon  {9241..  121 41}}} 
I  {REQ  #horl2ontal-dimension  {REQ  #fixed-dimension  {12401..17196}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 12141}}} 

-  up  to  Japanese  legal  landscape 

I  {REQ  #horl2ontal-dlmension  {REQ  #flxed-climension  {13200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {>=  16801}}} 
-  Any  portrait  size  larger  than  the  typical  foldout  size  (11  in  x  14  in)  including  11  inch  roll  paper.  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {>=  16801}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {13200}}} 

--  Any  landscape  size  larger  than  the  typical  foldout  size  (14  in  x  1 1  in)  including  1 1  inch  roll  paper  - 
") 

DEFINE(PermissiblePageDimensions," 

{REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 39680}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 56120}}} 

-  up  to  ISO  AO  portrait  -- 

I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1..56120}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 39680}}} 

--  up  to  ISO  AO  landscape 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 48000}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 21 1200}}} 

--  up  to  ANSI  J/K  portrait  -- 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 21 1200}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 48000}}} 

up  to  ANSI  J/K  landscape  - 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1.. 12141}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1..17196}}} 

--  up  to  Japanese  legal  portrait  -- 
I  {REQ  #horizontal-dimension  {REQ  #fixed-dimension  {1..17196}}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {1.. 12141}}} 

-  up  to  Japanese  legal  landscape  - 

") 

DEFINE(NominalPageSizes," 

-  ISO  Page  Sizes  - 

REQ  #horizontal-dimension  {7015}.  REQ  #vertical-dimension  {9920} 
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-  ISO  A5  Portrait 

REQ  #hoiizontal-dimension  {9920},  REQ  #vertlcal-dimension  {7015} 

ISO  A5  Landscape  - 
REQ  #horizontal-dimension  {9920},  REQ  #vertical-dimension  {14030} 

-  ISO  A4  Portrait  - 

REQ  #horl2ontal-dlmension  {14030},  REQ  #vertlcal-dimenslon  {9920} 

ISO  A4  Larxlscape  - 
REQ  #horizontal-dlmenslon  {14030},  REQ  #vertlcal-dimension  {19840} 

--  ISO  A3  Portrait  - 
REQ  #horlzontal-dimension  {19840}.  REQ  #vertical-dimenslon  {14030} 

-  ISO  A3  Landscape  - 

REQ  #horizontal-dlmension  {19840},  REQ  #vertical-dimension  {28060} 

--  ISO  A2  Portrait  -- 
REQ  #iiorizontal-dimension  {28060},  REQ  #vertical-dimension  {19840} 

-  ISO  A2  Landscape  - 

REQ  #liorizontal-dimension  {28060},  REQ  #vertical-dimension  {39680} 

-  ISO  A1  Portrait  -- 

REQ  # horizontal-dimension  {39680},  REQ  #vertlcal-dimension  {28060} 

-  ISO  A1  Landscape  - 

REQ  #horizontal-dimension  {39680},  REQ  #vertical-dimension  {56120} 

-  ISO  AO  Portrait  -- 

REQ  #horizontal-dimension  {56120},  REQ  #vertical-dimension  {39680} 

-  ISO  AO  1-andscape  - 


-  ANSI  Page  Sizes  - 

REQ  #horizontal-dimension  {10200},  REQ  #vertical-dimension 

--  ANSI  A  Portrait  -- 
REQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension 

-  ANSI  A  llandscape  -- 
REQ  #horizontal-dimension  {10200},  REQ  #vertical-dimension 

-  ANSI  Legal  Portrait  -- 
REQ  #horizontal-dimension  {16800},  REQ  #vertical-dimension 

--  ANSI  Legal  Landscape  - 
REQ  #horizontal-dimension  {13200},  REQ  #vertical-dlmension 

-  ANSI  B  Portrait  - 
REQ  #horlzontal-dimension  {20400},  REQ  #vertical-dlmension 

-  ANSI  B  Landscape  -- 
REQ  # horizontal-dimension  {20400},  REQ  #vertical-dimension 

~  ANSI  C  Portrait  ~ 
REQ  #horizontal-dimension  {26400},  REQ  #vertical-dimension 

~  ANSI  C  Landscape  ~ 
REQ  #horizontal-dimension  {26400},  REQ  #vertical-dimension 

~  ANSI  D  Portrait  ~ 
REQ  #horizontal-dimension  {40800},  REQ  #vertical-dimension 

~  ANSI  D  Landscape  ~ 
REQ  #horizontal-dimension  {40800},  REQ  #vertical-dimension 

~  ANSI  E  Portrait  - 
REQ  #horizontal-dimension  {52800},  REQ  #vertical-dimension 


13200} 
10200} 
16800} 
10200} 
20400} 
13200} 
26400} 
20400} 
40800} 
26400} 
52800} 
40800} 
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~  ANSI  E  Landscape  - 
I  REQ  #horlzontal-dimension  {33600},  REQ  #vertical-dimenslon  {48000} 

-  ANSI  F  Portrait  - 

1  REQ  #hori2ontal-dimenslon  {48000},  REQ  #vertlcal-dimension  {33600} 

-  ANSI  F  LarxJscape  - 

I  REQ  #horizontal-dlmension  {13200},  REQ  #vertical-dimension  {108000} 

-  ANSI  G  Portrait  - 

I  REQ  #horizontal-dimension  {108000},  REQ  #vertical-dimenslon  {13200} 

-  ANSI  G  Landscape  - 

I  REQ  #hori2ontal-dimension  {33600},  REQ  #vertical-dimenslon  {171600} 
ANSI  H  Portrait  -- 

I  REQ  #hoi1zontal-dimension  {171600},  REQ  #vertical-dimenslon  {33600} 

~  ANSI  H  Landscape  ~ 
I  REQ  #horlzontal-dimension  {40800},  REQ  #vertlcal-dlniension  {211200} 

--  ANSI  J  Portrait  - 
I  REQ  #horlzontal-dimension  {211200},  REQ  #vertical-dimension  {40800} 

-  ANSI  J  Landscape  -- 

I  REQ  #horizontal-dimension  {48000},  REQ  #vertical-dimension  {171600} 

-  ANSI  K  Portrait  - 

I  REQ  #horizontal-dimension  {171600},  REQ  #vertical-dimension  {48000} 

-  ANSI  K  Landscape  -- 

-  Foldouts  - 

I  REQ  #horlzontal-dimenslon  {13200},  REQ  #vertical-dimenslon  {16800} 

-  Foldout  Portrait  -- 

I  REQ  # horizontal-dimension  {16800},  REQ  #vertical-dimension  {13200} 

Foldout  LarxJscape  -- 
I  REQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension  {  >  =  16801} 

-  Any  portrait  size  larger  than  the  typical  foldout  size  (11  in  x  14  in)  including  1 1  inch  roll  paper  - 
I  REQ  #horizontal-dimension  {>=  16801},  REQ  #vertical-dimension  {13200} 

-  Any  landscape  size  larger  than  the  typical  foldout  size  (14  in  x  11  in)  including  11  inch  roll  paper  - 


") 


7.1.2 


Constituent  constraints 


7.1.2.1 


DocumentProflle 


{ 


~  Presence  of  document  constituents  -- 


REQ  Specific-layout-structure 
PERM  Presentation-styles 


{'present'}, 
{'present'}, 


~  Document  characteristics  ~ 
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REQ     Dcx:ument-application-profile    {-  See  clause  8  for  a  definition  of  the  permitted  values  for 

this  attribute.  -}. 

REQ     Document-application-profile-d^ults  { 

~  Document  architecture  defaults  ~ 


REQ 

PERM 

PERM 


#content-architecture-class 

#dimensions 

#medium-type 

PERM  #nominal-page-size 

PERM  #side-of-sheet 


{$FPR}. 

{$PermissiblePageDimensions}, 
{ 

{$NominalPageSizes}, 
{ANYVALUE}}, 


-  Any  permitted  medium  type.  Both  landscape  and  portrait  may  be  specified. 


REQ  #type-of-coding 


{ASN.1  {28370} 
I  ASN.1  {283  75} 
I  ASN.1  (283  76} 
{ANYVALUE}, 


-  T6  encoding  - 

-  tiled  encoding  - 

-  T6  encoding  -  MSB 


PERM  #page-position 

PERM  raster-graphics-contents-defauits  { 

PERM  #pel-path  {ANY  VALUE}, 

PERM  #line-progression         {ANY  VALUE}, 
PERM  #pel-spacing  {REQ  #length  {ANY  VALUE}, 

REQ  #pel-spaces  {ANY  VALUE}}, 

PERM  #spacing-ratio 

{REQ  #llne-spacing-value       {ANY  VALUE}, 
REQ  #pel-spacing-value         {ANY  VALUE}}, 

PERM  #compression  {ANY  VALUE}}, 


}. 


REQ 
REQ 

REQ 


REQ 


Document-architecture-class 
Content-architecture-classes 
Interchange-format-class 


ODA-version 

{REQ  #standard-or-recommendation 
REQ  #publication-date 


{$FDA}, 
{$FPR}, 

{--  This  attribute  required  only  for  ODIF 
interchange.  See  clause  8  for  a  definition  of  the 

permitted  value  for  this  attribute.  --}, 


{'ISO  8613'}, 
{'1991-12-31'}}, 

-  This  date  represents  the  date  that  this  DAP  was  approved.  This  is  the  only 

-  approved  value,  however,  the  date  will  be  changed  if  the  DAP  is  significantly 

-  revised.  If  the  date  is  revised,  use  of  the  new  date  is  required  only  when  the 

-  additional  functionality  is  t>eing  used.  That  is,  legacy  products  may  continue  to 

-  support  the  earlier  DAP. 


Non-basic  document  characteristics  ~ 

PERM  Page-dimensions 

PERM  Medium-types 

PERM  #  nominal-page-size 
PERM  #side-of-sheet 


{MUL  {$NonBas!cPageDimensions}}, 
{MUL{ 

{  $NominalPageSizes  }, 
{ANY  VALUE}}}, 
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-  All  values  of  "medium  type"  are  non-basic  - 
PERM  Coding-attributes  { 

REQ  #raster-graphics-coding-attributes  { 

REQ  #compresslon  {'uncompressed'}}}, 

PERM  Presentation-features  { 

PERM  #Raster-graphics-presentation-features   {  MUL  { 


PERM 

PERM 
PERM 


I  PERM 


#pel-path 

#lin8-progression 
#pel-spaclng 


{'180-degrees'  | 

'270-degrees'} 

{'90-degrees'} 

{REQ  #length  {ANY  VALUE} 
EXCEPT  {16.12.8.6.5.4.3.2.1}. 
REQ  #pel-spaces  {ANYVALUE} 
EXCEPT 
{1}} 


#spacing-ratio 

{REQ  #line-spacing-value 

REQ  #pel-spacing-value 


{ANY  VALUE}  EXCEPT 
{1}. 

{ANY_VALUE}  EXCEPT 
{1}]}}}. 


~  Document  management  attributes  ~ 


-  Document  description  ~ 
REQ  Document-reference 


} 


{ANYVALUE} 


7.2  Logical  constituent  constraints 

No  logical  constituents  applicable  in  this  clause. 

7.3  Layout  constituent  constraints 


7.3.1       Macro  definitions 

DEFINE(RAST."  CONTENTJD_OF(Raster-graphics-content-portion)") 
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7.3.2       Factor  constraints 

FACTOR  ANY-LAYOUT  { 


{VIRTUAL}. 

{ANYVALUE}. 

{VIRTUAL}, 

{ANYVALUE}. 

{ANYVALUE} 


SPECIFIC: 

PERM  Object-type 

REQ  Object-identifier 

PERM  Subordinates 

PERM  User-visible-name 

PERM  User-readable-connments 

} 


7.3.3       Constituent  constraints 


7.3.3.1  DocumentLayoutRoot 

DocumentLayoutRoot:  ANY-LAYOUT  { 


SPECIFIC: 

REQ  Object-type 

REQ  Subordinates 

} 


7.3.3.2 


CompositePage 


CompositePage: 


SPECIFIC: 


REQ 

REQ 

PERM 

PERM 

PERM 


Object-type 

Subordinates 

Dimensions 

Page-position 

Medium-type 


PERM  Application-comments 
} 


{  'document-layout-root'}, 
{SUBJD_OF(CompositePage)  +  } 


ANY-LAYOUT  { 


{'page'}, 

{SUB_ID_OF(lmageFrame)}, 

{$PermissiblePageDimensions}, 

{ANY_VALUE}, 

{PERM  # nominal-page-size  {$NominalPageSizes}, 
PERM  #side-of-sheet  {ANY  VALUE}}, 
{ANY  VALUE} 


7.3.3.3  ImageFrame 

ImageFrame:  ANY-LAYOUT  { 
SPECIFIC: 

REQ     Object-type  {'frame'}, 

REQ     Subordinates  {SUB_ID_OF(SpecificBlock)}, 

PERM  Application-comments  {ANY  VALUE} 
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7.3.3.4  SpecmcBlock 

SpecificBlock 

SPEOFIC: 
REQ  Object-type 
REQ  Object-identifier 
REQ  Content-portions 
PERM  Position 


PERM  Dimensions 


PERM  Content-architecture-dass 

PERM  User-readable-comments 

PERM  User-visible-name 

PERM  Application-comments 

PERM  Presentation-style 

~  PStyle  for  raster  content  - 

PERM  Presentation-attributes 

PERM  #raster-grapliics-attribiJtes 
PERM  #pel-path 
PERM  #line-progression 
PERM  #pel-spacing 

PERM  #spacing-ratio 

PERM  #clipping 

} 

7.4     Layout  style  constraints 

No  layout  style  constraints  applicable  in  tliis  d 


{'block'}. 

{ANY_VALUE}. 

{$RAST}. 

{REQ  #fixed-positk>n  { 

REQ  #horlzontal-positlon  {ANY  VALUE}. 

REQ  #vertteal-posltton  {AI^  VALUE}}}, 
{REQ  #liorizontal-dlmension 

{REQ  #flxed-dlmension{ANY_VALUE}}. 
REQ  #vertical-dimension 

{REQ  #fixed-dlmenslon{ANY_VALUE}}}. 

{$FPR}. 

{ANY_STRING}. 

{ANYSTRING}. 

{ANY_VALUE}. 

~  See  8.1.3  and  8.2.3  -- 

{STYLEJD_OF(PStyle)}. 

{ 

{ 

{ANY_VALUE}, 
{ANY  VALUE}, 
{REQ'^length  {ANY  VALUE}. 
REQ  #pel-spaces  {ANY  VALUE}}. 
{REQ  #line-spacing-value  {ANY  VALUE}. 
REQ  #pei-spacing-value  {ANY  VALUE}}. 
{ANY  VALUE}}} 
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7.5     Presentation  style  constraints 

7.5.1  Macro  definitions 

No  macro  definitions  are  applicalsle  to  tiiis  clause. 

7.5.2  Factor  constraints 

FACTOR  ANY-PRESENTATION-STYLE  { 

REQ     Presentation-style-identirier  {ANY  VALUE}. 

PERM  User-readable-comments  {ANY~STRING}. 
PERM  User-vlsiWe-name  {ANY~STRING} 
} 

7.5.3  Presentation  style  constituent  constraint 
7.5.3.1  PStyle 

PStyle:  ANY-PRESENTATION-STYLE  { 

-  This  style  is  used  for  raster  graphics  content  - 

PERM  Presentatton-attributes  { 
PERM  #raster-graphics-attributes  { 


PERM  #pel-path 
PERM  #line-progresslon 
PERM  #pei-spacing 


PERM  #cllpping 


PERM  #spacing-ratio 


{ANYVALUE}, 
{ANYVALUE}. 
{REQ  #length  {ANY  VALUE}. 
REQ  #pei-spaces  {ANY  VALUE}}, 
{REQ  #llne-spaclng-value  {ANY  VALUE}, 
REQ  #pel-spacing-value  {ANY_VALUE}}. 
{ANYVALUE}}} 


} 


7.6      Content  portion  constraints 


7.6.1 


Macro  definitions 


DERNECTILED." 


ASN.1  {2837  5}")  -  Tiled  raster  encoding  - 
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No  fector  constraints  are  applicable  to  this  dause. 


7.6.3       Constttuent  constraints 


7.6.3.1 


Raster  graphics  content  portion 


Raster-graphlcs-content-portlon 
REQ  Content-identifier-layoLit 
PERM  Type-of-coding 


{ 


{ANYVALUE}. 

{  ASN.1{2  8  3  70}  - T.6  encoding - 

I  ASN.1  {2  8  3  7  1 }  -  T.4  one  dimensional - 

j  ASN.1  {28372}  -  T.4  two  dimensional  - 

I  ASN.1  {2  8  3  7  3}  -  bitmap  encoding  - 

I  ASN.1  {2  8  3  7  5}  ~  tHed  encoding  - 

I  ASN.1  {2  8  3  7  6}  ~  T.6  encoding  •  MSB  - 

I  ASN.1  {2  8  3  7  7}  ~  T.4  one  dimei^slonal  -  MSB  - 

I  ASN.1  {28378}  -  T.4  two  dimensional  -  MSB  -  }. 


PERM  Coding-attributes  { 
REQ     #raster-graphics-coding-attribLites  { 

PERM  #compresslon  {ANY  VALUE}. 

PERM  #number-of-lines  {>0}7 
REQ    #number-of-pels-per-line  {>0}, 
CASE  Raster-graphics-content-portton  (Type-of-coding)  OF  { 


{$TILED}: 


{PERM  #number-of-pels-per-tile-line  {512}. 


PERM  #number-of-lines-per-tile 
PERM  #tiling-offset 
PERM  #tile-types 


PERM 
PERM 
} 


Alternative-representation 
Content-information 


{ANY  STRING}. 
{RASTER} 


{512}. 

{ANYVALUE}. 
{'null  background'  | 
'null  foreground'  | 
T.6  encoded'  | 
'bitmap  encoded'  | 
T.6  encoded  -  MSB'}}}}. 
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8     Interchange  format 

Two  interchange  formats  are  supported  by  this  profile.  The  interchange  fomrtat  ODIF  (class  A)  can  be  used 
by  applications  requiring  a  binary  encoding  based  on  ASN.1.  The  interchange  Format  SDIF  can  be  used 
by  applications  requiring  a  SGML  based  clear  text  encoding.  This  latter  interchange  format  is  an  SGML 
application,  called  Office  Document  l-anguage  (ODL).  For  the  purposes  of  interchange,  the  ODL  ENTITIES 
are  placed  in  an  ASN.1  wrapper,  as  defined  by  SDIF.  Each  encoding  form  has  inherent  advantages. 
Conversion  of  document  encoded  in  one  interchange  format  into  the  other  should  not  produce  the  loss  of 
semantic  document  information. 


8.1      Interchange  format  ODIF  (class  A) 


8.1.1       Interchange  format 

The  value  of  the  document  profile  attribute  "interchange  format"  for  this  interchange  format  is  'if-a'.  This  form 
of  ODIF  is  defined  in  ISO  8613-5. 

The  encoding  is  in  accordance  with  the  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1), 
as  defined  in  ISO  8825. 


8.1.2       DAP  identifier 

The  value  for  the  document  profile  attribute  "document  application  profile"  for  this  interchange  format  is 
represented  by  the  following  object  identifier. 

iso  (1)  identified-organization  (3)  oiw  (14)  odasig  (11)  image-appi  (1)  raster-dap-odif  (1) 


8.1 .3       Encoding  of  application  comments 

ISO  8613-5  define  the  encoding  of  the  attribute  "application  comments"  as  an  octet  string.  For 
Specif icBlock,  this  DAP  requires  that  the  encoding  within  that  octet  string  be  in  accordance  with  the  ASN.1 
syntax  specified  in  the  following  module  definition. 

NIST-DAPSpecification 

DEFINITIONS  ::=  BEGIN 

EXPORTS  Object-Appl-Comm-Encoding; 

Object-Appl-Comm-Encoding  ::=  SEQUENCE  OF  INTEGER 
END 
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8.2      Interchange  format  SDIF 


8.2.1       Interchange  format 

The  document  profile  attribute  "Interchange  format"  does  not  apply  for  this  Interchange  format.  The  SDIF 
encoding  of  ODA  Is  defined  In  Annex  E  of  ISO  8613-5.  In  addition,  ISO  8613-7  contains  additlonaJ 
specifications  for  this  encoding  of  ODA. 


8.2.2       DAP  identifier 

The  value  for  this  attribute  "document  application  profile"  for  this  Interchange  format  is  represented  by  the 
following  object  identifier. 

iso  (1)  identified-organization  (3)  oiw  (14)  odasig  (11)  image-appi  (1)  raster-dap-sdif  (2) 


8.2.3       Encoding  of  application  comments 

For  SpecificBioclc.  the  encoding  of  the  attribute  "application  comments"  is  defined  In  a  data  stream 
conforming  to  this  profile  with  the  following  DTD  definition: 

<  I-  The  following  set  of  declarations  may  be  invol<ed  by  using  a  public  entity  as  follows: 

<  IDOCTYPE  odaac  Public  "-//USA-OIW//DTD  SGML  ENCODING  ODA  APPLICATION  COMMENTS//EN"> 
-> 

<l~  NOTE:  To  parse  the  following  Document  Type  Declaration  Subset,  place  the  Document  Type 
declaration"  <  IDOCTYPE  odaac  I"  at  the  beginning  of  the  file  and  "]>"  at  the  end  of  the  file.  ~> 

<!ELEMENT  odaac  -  -  (objappc)+  > 

<!-  Object  application  comment  ~> 
<IELEiy/IENT  objappc  -  O  (#PCDATA)> 

8.3      Encoding  of  raster  content  information 

The  encoding  of  raster  content  information  in  the  bitmap  encoding  scheme  is  that  specified  in  9.3  of  the 
raster  graphics  content  architecture  part  of  ISO  8613-7,  that  is,  the  first  pel  in  the  order  of  bits  is  allocated 
to  the  most  significant  bit  of  an  octet.  The  encoding  of  the  code  words  in  the  CCITT  Recommendation  T.4 
and  T.6  encoding  schemes  may  be  done  in  either  the  up  or  down  bit  order.  The  bit  order  is  specified  by 
the  attributes  "type  of  coding"  or  "tile  types".  The  attribute  "tile  types"  is  used  only  when  the  value  for  "tyoe 
of  coding"  Is  'tiled  encoded'.  For  the  up  order,  it  is  such  that  the  first  or  only  bit  of  the  first  code  word  shall 
be  placed  In  the  least  significant  bit  of  the  first  octet.  Subsequent  bits  of  the  first  and  following  code  words 
are  placed  In  the  direction  of  more  significant  bits  in  the  first  and  following  octets.  For  the  down  order,  It 
Is  such  that  the  first  or  only  bit  of  the  first  code  word  shall  t>e  placed  in  the  most  significant  bit  (MSB)  of  the 
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first  octet.  Subsequent  bits  of  the  first  and  following  code  words  are  placed  in  the  direction  of  least 
significant  bits  In  the  first  and  foiiowing  octets. 


26 


PART  23  -  ODA  Raster  DAP 


December  1992  (Stable) 


Annex  A  (normative) 
Amendments  and  corrigenda 

A.1  Amendments 

A.1.1       Amendments  to  the  base  standard 

The  amendments  applicable  to  this  DAP  includes  the  ISO  8613  -  Amendment  1:  1990.  This  amendment 
includes  text  to  be  included  in  ISO  8613-1  as  the  following  annexes: 

a)  Annex  E:  Use  of  ISO/IEC  10021  (MOTIS)  to  interchange  documents  conforming  to  ISO  8613; 

b)  Annex  F:  Document  application  profile  proforma  and  notation; 

c)  Annex  G:  Conformance  testing  methodology; 

d)  Annex  H:  Recording  of  documents  conforming  to  ISO  8613  on  flexible  disk  cartridges 
confomning  to  ISO  9293. 

In  addition,  this  amendment  addresses  the  inclusion  of  the  ISO  8613  Technical  Conlgenda  1. 

This  DAP  does  not  include  the  following  features  of  the  amendment: 

a)  Addendum  on  security; 

b)  Addendum  on  styles; 

c)  Addendum  on  alternative  representation. 

Additionally,  this  DAP  includes  features  from  the  Tiled  Raster  Graphics  Addendum  to  ISO  8613-7,  ISO/IEC 
JTC1  /SC18/WG5  901,  dated  September  1990.  and  the  Additional  Bit  Order  Mapping  Addendum  to  CCITT 
Rec.  T.417|ISO  8613-7,  ISO/IEC  JTC  1/WG  3.  dated  July  1991.  A  new  version  of  ISO  8613-7  which  also 
will  incorporate  the  Colour  Addendum  is  scheduled  to  be  issued  in  1993. 

A.2  Corrigenda 

A.2.1       Corrigenda  to  this  DAP 

There  are  no  corrigenda  to  this  DAP. 
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Annex  B  (informative) 
Recommended  practices 


B.1      Transfer  methods  for  ODA 


B.1.1       Conveyance  of  ODA  over  CCITT  X.400-1984 

This  recommendation  describes  liow  ODA  body  parts  are  to  be  encoded  for  transmission  over  a  CCITT 
X.400-1984  service. 

An  ODA  body  part  is  encoded  as  OdaBodyPart  in  tiie  definition  given  below: 


OdaBodyPart  ::=  SEQUENCE  {  OdaBodyPartParameters,  OdaData  } 
OdaBodyPartParameters  ::=  SET  { 
document-appiication-profile 

[0]  IMPLICIT  OBJECT  IDENTIFIER, 
document-architecture-class 

[1]  IMPLICIT  INTEGER  { 
formatted  (0), 
processable  (1), 
formatted-processable  (2)  } 
OdaData  ::=     SEQUENCE  OF  Interchange-Data-Element 


NOTE  -  It  is  recommended  to  transfer  an  ODA  document  as  a  single  txxJy  part  with  tag  12: 
Oda  [12]  IMPLICIT  OCTETSTRING 

The  content  of  the  octet  string  is  encoded  as  OdaBodyPart,  defined  above.  IHowever,  this  Is  out 
of  the  scope  of  this  profile. 


B.1 .2       Conveyance  of  ODA  over  FTAM 

This  recommendation  describes  the  File  Transfer,  Access,  and  Management  (FTAM)  Document  Type  to  be 
used  for  minimal  storage  and  transfer  capabilities  of  ODA  data  streams.  It  is  recognized  that  enhanced 
capabilities  may  at  some  point  be  added. 

When  using  FTAM  to  transfer  an  ODA  file,  the  FTAM-3,  "ISO  FTAM  Unstructured  Binar/,  document  type 
should  be  specified.  Hovy^ever,  since  files  that  do  not  contain  ODA  data  streams  can  have  the  same 
document  type,  it  is  left  up  to  the  user  of  application  programs  that  remotely  access  files  using  FTAM  to 
know  that  a  given  file  contains  an  ODA  data  stream. 
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B.I. 3      Conveyance  of  ODA  over  DTAM 

This  recommendation  provides  for  information  concerning  tlie  interchange  of  ODA  based  documents  with 
Document  Transfer  and  Manipulation  (DTAi\^)  protocols. 

DTAM  is  defined  in  the  T.430-Series  of  recommendations  and  is,  Wke  ODA,  an  integral  part  of  the  T.400- 
Series  of  CCITT  Recommendations  named  Open  Document  Architecture,  Transfer  and  Manipulation. 

The  T.520-Serie8  of  recommendations  contain  Communication  Application  Profiles  (CAP).  Recommendation 
7.522  describes  the  Communication  Application  Profile  BT1  for  document  bulk  transfer.  Recommendation 
7.522  is  applicable  for  the  Office  Document  Format  Profile  (FOD)  published  in  this  ISP. 

NOTE  -  The  use  of  BT1  within  the  end-to-end  oriented  Telematic  Services  Telefax  4  and  Teletex  is  descn'bed 
in  7.1  of  Recommendation  T.561  and  7.1  of  Recommendation  T.562. 


B.I  .4      Conveyance  of  ODA  over  flexible  disks 

The  recommended  method  for  interchanging  ODA  documents  between  systems  by  the  exciiange  of 
magnetically  recorded  Rexible  Disi<  Cartridges  is  by  the  use  of  an  annex  to  ISO  8613-1  (to  be  publisfied), 
Receding  of  Documents  Conforming  to  ISO  8613  on  Flexible  Cartridges  Conforming  to  ISO  9293.  This 
annex  provides  for  recording  each  ODA  document  as  a  separate  file  as  defined  by  ISO  9293,  Volume  and 
File  Structure  of  Flexible  Disk  Cartridges  for  Information  Interchange. 

NOTE  -  Document  encoded  in  ODL  can  be  stored  such  that  each  SGML  ENTITY  is  recorded  in  a  separate 
file  or  in  the  case  of  an  SDIF  encoding,  the  file  can  be  stored  in  a  single  file. 

B.2     Interoperability  with  SGML  applications 

The  recommended  method  for  the  exciiange  of  documents  t}etween  Standard  Generalized  Martojp 
language  (ISO  8879,  SGML)  based  systems  and  systems  based  on  this  ODA  document  application  profile 
is  by  means  of  exchanging  a  document  representation  conforming  to  these  agreements  in  an  encoded  form 
of  the  SGML  language  known  as  the  Office  Document  Language  (ODL).  ODL  is  a  standardized  SGML 
application  for  representing  documents  conforming  to  the  ODA  base  standard.  Such  a  representatton  can 
be  converted  into  the  Office  Document  Interchange  Format  (ODIF)  supported  by  this  document  application 
profile. 
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Annex  C  (informative)  

References  to  other  standards  and  registers 

CCnr  Recommendation  T.400  : 1988.  Introduction  to  Document  Architecture,  Transfer  and  Manipulation; 

CCITT  Recommendation  T.411  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Introduction  and  General  Principles; 

CCITT  Recommendation  T.412  :  1988.  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Structures; 

CCITT  Recommendation  T.414  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Profile; 

CCITT  Recommendation  T.415  : 1988,  Open  Document  Architecture  (ODA)  and  interchange  Format:  Open 
Document  Interchange  Format; 

CCITT  Recommendation  T.417 : 1988.  Open  Document  Architecture  (ODA)  and  Interchange  Format:  Raster 
Graphics  Content  Architecture; 

CCITT  Recommendation  T.503 : 1 984.  Document  Application  Profile  for  the  interchange  of  Group  4  Facsimie 
Documents; 

ISO  8571  : 1988,  Information  processing  systems  -  Open  Systems  Interconnection  -  FHe  transfer,  access  and 
management; 

ISO  9070 : 1990,  Infonnation  processing  -  SGML  support  teciities  -  Registration  procedures  for  public  owner 
identifiers; 

ISO/TR  9573  : 1988.  Information  processing  -  SGML  technical  report  -  Techniques  for  using  SGML; 

ISO  10021  :  (to  be  published).  Information  processing  systems  -  Text  communication  -  Message  Oriented 
Text  Interchange  System; 

ISP  FOD26  :  (to  be  pubiisfied).  Office  document  format  profile  for  the  interchange  of  enhanced  function 
mixed  content  documents  in  processat)le  and  formatted  forms; 

ISP  FOD36  :  (to  be  published).  Office  document  format  profile  for  the  interchange  of  tended  function 
mixed  content  documents  in  processable  and  formatted  forms; 

MIL-R-28002A  :  1990.  MIUTARY  SPECIFICATION.  RASTER  GRAPHICS  REPRESENTATION  IN  BINARY 
FORMAT.  REQUIREMENTS  FOR. 
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Annex  D  (informative) 

Supplementary  information  on  attributes 


Table  D.I  -  Content  coding  attiibutet 


Attributes 

Basic  values 

DefauK  values 

Non-t>ssic 
vslues 

Number-of-pels-per-line 

any  positive  integer 

None 

None  1 

Numb6r-of-lin6S 

any  positive  integer 

None 

None  1 

Tiling-offset* 

(any  non-negative  integer 
<  512,  any  non-negative 
integer  <  512) 

(0,0) 

None  1 

Tile-types* 

T.6  encoded,  bitmap 
encoded,  null 
background,  null 
foreground,  T.6  encoded  - 
MSB 

T.6  encoded 

None 


Type-of-coding 

T.6  encoding  (untiled), 
bitmap  (untiled),  tiled 
encoded,  T.4  ID 
encoding,  T.4  2D 
encoding,  T.6  encoding  - 
MSB  (untiled),  T.4  1D 
encoding  -  MSB,  T.4  2D 
encoding  -  MSB 

T.6  encoding,  T.6 
encoding  -  MSB,  tiled 
encoding  ** 

None 

Tutorial  Note  -  *  Only  used  if  "type  of  coding'  is  'tiled  encoded' 


Tutorial  Note  -  **  As  specified  in  the  document  profile 


Table  D.2  -  Presentation  attributes 


Attributes 

Basic  values 

DefauK  values 

Non-basic  values 

Pel-path 

0,  90  deg 

0  deg 

180,  270  deg 

Line-progression 

270  deg 

270  deg 

90  deg 

Pel-spacing 

16,  12,  8.  6,  5,  4,  3,  2,  1 
BMU 

4  BMU  (300) 

Any  value  except 
'null- 

Clipping 

Two  Coordinate  Pairs 
(any  non-negative  integer, 
any  non-negative  integer) 

(0,0).  (N-1,  L-1) 

None 
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TabSe  D.3  -  Document  profile  attributes 


Attribute 

Class 

— 1_—  ==ggeaasaaa 

Permissibie  values  I 

Spedfio-layout-staicture 

 _____ 

m 

present 

Pro86ntation-8tyles 

nm 

present 

Document-characteristics 

M 

Document-architecture-dass 

m 

formatted 

Dccument-applicaticrvprofile 

m 

{—  See  clause  8  for  a  definition  of  the 
permitted  values  fOr  this  attribute.  -} 

Content-architecture-classes 

m 

{28272} 

Interchange-fbrmat-class 

m 

A 

ODA-version 

m 

ISO  8613,  1991-12-31 

B  Document-architecture-defaults 

M 

Content-architecture-class 

m 

formatted  processable  raster  graphics 

Type-of-coding 

m 

T.6  encoding,  tiled  encoding,  T.6 
encoding  -  MSB 

Page-dimensions 

nm 

See  list  in  table  1,  (Default  value  is  NA- 

K  9240  X  13200  BMU) 

Medium-types 

nm 

See  list  in  table  1,  (Default  value  is  NA- 
A,  9240  X  13200  BMU) 

1  Paae-Dosition 

_____ 

mm 

any  coordinate  pair  within  page 

1  Raster-gr-content-defaults 

NM 

Pel-path 

nm 

0,  90,  180,  270  degrees  (0  is  normal  1 
default)  1 

Line-progression 

nm 

SO,  270  degrees  (270  is  normal  default)  | 

Pel-spacing 

nm 

16,  12,  B,  e  5.  4,  3,  2,  1  BMU,  (Normal 
default  is  4  BMU) 

 1 

Spacing  Ratio 

nm 

Any  value 

Non-t>asic-doc-characteristics 

NM 

Page-dimensions 

nm 

See  table  1 

Mediunvtypes 

nm 

See  table  1  | 
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 Table  D.3  -  Document  pyoflle  attributes  (conduded) 


Attribut* 

Class 

Permissible  values 

Raster-gr-presentatiorvfeatures 

NM 

Pel-path 

nm 

180.  270  degrees 

Line-progression 

nm 

90  degrees 

Pel-spadng 

nm 

Any  value  except  16,  12,  8,  6,  5,  4,  3,  2, 
or  1  BMU 

Docunrrant-managemenft-attributes 

M 

Document  Reference 

m 

Any  string  of  characters 

The  following  notation  is  used  in  the  class  column  of  this  table: 

a)  m  mandatory  attribute 

b)  nm  non-mandatory  attribute 

c)  d  defaultable  attribute 

Capital  letters  (M.  NM.  and  D)  are  used  for  groups  of  attributes. 
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Annex  E  (informative) 
Register  index 


Table  E.I  -  Object  identifiers 


1  ObjMl  idantlfiM- 

Reference 

iso  (1)  identified-organization  (3)  oiw  (14)  odasig  (11) 
image-appi  (1)  raster-dap-odif  (1) 

8.1.2 

iso  (1)  identifiacl-organization  (3)  oiw  (14)  odasig  (11) 
image-appI  (1)  raster-dap-sdif  (2) 

1 

34 


stable  Implementation 
Agreements  for  Open  Systems 
Interconnection  Protocols: 
Part  24  -  Conformance  Testing 


Output  from  the  December  1992  Open  Systems 
Environment  Implementors'  Workshop  (OIW) 


SIG  Chair:  Eva  Kuiper,  Hewlett  Packard 
Workshop  Editor:       Brenda  Gray,  NIST 


PART  24  -  Conformance  Testing 


December  1992  (Stable) 


Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Conformance  Testing  Special 
Interest  Group  (CTSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 

Text  in  this  part  has  t>een  approved  by  the  Plenary  of  the  above-mentioned  Workshop. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part.  Deleted  and  replaced  text  will  be  shown  as  struck.  New  and  replacement  text  will  be  shown  as 
shaded. 
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1  Scope 

(Refer  to  Working  Implementation  Agreements  Document) 

2  Normative  References 

(Refer  to  Working  Implementation  Agreements  Document) 

3  Status 

Tfiis  material  is  current  as  of  December  18,  1992. 

4  Errata 

Errata  will  be  reflected  in  replacement  pages  of  Version  6,  Stable  Document. 

5  Guidelines  on  interpretation  of  Disputed  Test  Cases 
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7    CT  SIG  Resolution  for  FTAM 

(Refer  to  Working  Implementation  Agreements  Document) 


8    Guidelines  for  PCTR  Test  Campaign  Summary 

The  following  table  provides  guidelines  for  fiandling  the  "selected",  "not  run"  and  "observations"  columns  in 
a  Protocol  Conformance  Test  Report.  In  the  following  table,  the  "criterion"  column  in  taken  with  the  "test  case 
status"  column  to  give  the  expected  contents  of  the  three  PCTR  columns.  Note  that  this  table  does  not 
contain  ail  possible  permutations  of  PICS  support  answer,  lUT  behavior,  and  test  case  status.  The  primary 
focus  of  this  table  is  to  provide  PCTR  guidelines  for  the  permutations  of  "test  case  status". 
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Table  1  -  Guidelines  for  the  use  of  the  "Selected"  and  "Not  Run"  columns  in  a  PCTR 


1  Criterion                                                          PCTR              PCTR                PCTR  1 
1                                                                    selected            not  run              observation  1 
1                                                                       column             colunnn               column  J 

1.   TEST  DESELECTED 

1 .  feature  not  implemented 

deselect 

<  empty  > 

<empty>  (f) 

2.  feature  not  applicable 

deselect 

<  empty  > 

<empty> 

II.  TEST  SELECTED;  TEST  PURPOSE  NOT  ACHIEVED 

1.  ATS  defect;  no  error 
in  standard 

select 

not  run 

(g) 

ATS  error 
{a.c) 

2.  ATS  defect;  error  or 
ambiguity  in  standard 

select 

not  run 

(g) 

ATS  error 
(a.c) 

3.  ETS  defect 

select 

not  run 

(g) 

ETS  error 
(a.b.c) 

4.   No  defect;   Inconclusive  verdict 

select 

run 

manual 
analysis 
(c.d) 

III.  TEST  SELECTED;  TEST  PURPOSE  ACHIEVED 

1 .  Test  is  defect-free 

select 

run 

<  empty  > 
(e) 

2.  ETS/ATS  defect; 
wori<around  available 

select 

run 

manual 
analysis 
alternate 
verdict 
(b.c.d) 

See  Notes  listed  below: 

a)  This  criteria  includes  any  test  where  the  test  purpose  cannot  be  achieved  by  an  lUT  exhibiting 
valid  behavior. 

b)  This  criteria  includes  any  test  where  the  ETC  attempts  to  accomplish  the  test  purpose  in  an 
overly  restrictive  way,  resulting  in  an  Inconclusive  test  case  verdict,  even  though  the  lUT  exhibits 
valid  behavior.  Manual  analysis  instructions  are  provided  by  the  MOT  supplier  for  such  tests.  These 
Instructions  are  used  by  the  test  lab  to  determine  whether  the  test  purpose  can  be  achieved.  If  the 
analysis  shows  that  the  test  purpose  cannot  be  achieved,  the  PCTR  indicates  this  test  as  "Not  Run". 
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Iff  the  aralysis  shows  that  the  test  purpose  can  be  achieved,  the  PCTR  indicates  this  test  as  "Run". 

c)  The  Ot>8eivation  must  include  the  MOT  supplier's  Defect  Report  number  or  a  reference  to  official 
MOT  documentation  (such  as  the  release  notes  or  test  specifications)  or  corrective  action.  If  the 
MOT  supplier  does  not  agree  that  the  test  case  is  defective,  then  the  observation  must  include  a 
standard  and/or  profile  justification.  If  the  defect  is  iUT  specific,  the  observation  must  include  a 
test'-specific  Justification,  or  a  reference  to  one.  The  observation  must  fully  and  adequately  explain 
why  the  llTTs  behavior  is  valid. 

d)  The  Observation  must  include  a  test-specific  justification  of  verdict.  Analysis  of  IUT  t)ehavior 
reveals  no  evidence  of  non-conformance  and  no  Icnow  impact  on  interworking.  Manual  analyste 
also  reveals  no  evidence  df  ATC/ETC  defect. 

e)  An  observation  is  needed  only  if  the  test  case  verdict  in  not  Pass. 

f)  It  is  recommended  that  the  observation  column  contain  a  reference  to  the  test  case  selection 
expression  used  to  de-select  the  test  case.  If  the  obseo/ation  column  is  empty  for  a  particular  item, 
which  has  been  de-selected,  the  default  meaning  is  that  the  item  was  de-selected  based  on  the 
PICS.  If  the  test  is  deselected  for  PIXIT  reasons,  the  reference  is  mandatory. 

g)  The  term  "not  run"  as  used  here  is  not  the  normal  English  usage  of  the  term.  See  ISO/IEC 
9646-5  for  the  meaning  of  the  "run"  column  of  the  PCTR.  When  'not  run"  appears  in  the  run  column 
of  the  PCTR  it  indicates  a  situation  in  which  there  is  an  ATS  or  ETS  error. 


I 


-  'f 


1 


4 


Stable  Implementation 
Agreements  for  Open  Systems 
Interconnection  Protocols: 
Part  25  -  Health  Care 


Output  from  the  December  1992  Open  Systems 
Environment  Implementors'  Workshop  (OIW) 


i 


SIG  Chair:  John  J.  Harrington,  Hewlett  Packard 

Workshop  Editor:       Brenda  Gray,  NIST 


PART  25  -  Haalth  Care 


December  1992  (Stable) 


Foreword 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Open  Systems  Environment 
Technical  Committee  (OSE  TC)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 

This  text  was  approved  by  the  Plenary  of  the  Workshop. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part  with  redline  (shaded)  for  next  text  and  stikeout  (--)  for  deleted  text. 
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Editor's  Note  -  Text  for  the  Level  2  to  Level  3  Migration  DAP  vtnll  be  moved  here  from  the  Working 
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•  U.S.  G.P.0.:1993-341-931 :82606 


ANNOUNCEMENT  OF  NEW  PUBLICATIONS  ON 
COMPUTER  SYSTEMS  TECHNOLOGY 


Superintendent  of  Documents 
Oovemment  Printing  Office 
Washington,  DC  20402 


Dear  Sir: 

Please  add  my  name  to  the  announcement  list  of  new  publications  to  be  istiiued  in 
the  series:  National  Institute  of  Standards  and  Technology  Special  Publication  500>. 

Name  ]  

Company  

Address  

City  State   Zip  Code  


(NotifkaUon  key  N^) 


imLJ  J.  Technical  Publications 

Periodical 


Journal  of  Research  of  the  National  Institute  of  Standards  and  Technology  -  Reports  NIST 
research  and  development  in  those  disciplines  of  the  physical  and  engineering  sciences  in  which 
the  Institute  is  active.  These  include  physicsi  chemistry,  engineering,  mathematics,  and  computer 
sciences.  Papers  cover  a  broad  range  of  subjects,  with  major  emphasis  on  measurement 
methodology  and  the  basic  technology  underlying  standardization.  Also  included  from  time  to  time 
are  survey  articles  on  topics  closely  related  to  the  Institute's  technical  and  scientific  programs. 
Issued  six  times  a  year. 


Nonperiodicals 


Monographs  —  Major  contributions  to  the  technical  literature  on  various  subjects  related  to  the 
Institute's  scientific  and  technical  activities. 

Handbooks  —  Recommended  codes  of  engineering  and  industrial  practice  (including  safety  codes) 
developed  in  cooperation  with  interested  industries,  professional  organizations,  and  regulatory 
bodies. 

Special  Publications  — Include  proceedings  of  conferences  sponsored  by  NIST,  NIST  annual 
reports,  and  other  special  publications  appropriate  to  this  grouping  such  as  wall  charts,  pocket 
cards,  and  bibliographies. 

Applied  Mathematics  Series  — Mathematical  tables,  manuals,  and  studies  of  special  interest  to 
physicists,  engineers,  chemists,  biologists,  mathematicians,  computer  programmers,  and  others 
engaged  in  scientific  and  technical  work. 

National  Standard  Reference  Data  Series  —  Provides  quantitative  data  on  the  physical  and  chemical 
properties  of  materials,  compiled  from  the  world's  literature  and  critically  evaluated.  Developed 
under  a  worldwide  program  coordinated  by  NIST  under  the  authority  of  the  National  Standard 
Data  Act  (Public  Law  90-396).  NOTE:  The  Journal  of  Physical  and  Chemical  Reference  Data 
(JPCRD)  is  published  bimonthly  for  NIST  by  the  American  Chemical  Society  (ACS)  and  the 
American  Institute  of  Physics  (AIP).  Subscriptions,  reprints,  and  supplements  are  available  from 
ACS,  1155  Sixteenth  St.,  NW.,  Washington,  DC  20056. 

Building  Science  Series  —  Disseminates  technical  information  developed  at  the  Institute  on  building 
materials,  components,  systems,  and  whole  structures.  The  series  presents  research  results,  test 
methods,  and  performance  criteria  related  to  the  structural  and  environmental  functions  and  the 
durability  and  safety  characteristics  of  building  elements  and  systems. 

Technical  Notes  — Studies  or  reports  which  are  complete  in  themselves  but  restrictive  in  their 
treatment  of  a  subject.  Analogous  to  monographs  but  not  so  comprehensive  in  scope  or  definitive 
in  treatment  of  the  subject  area.  Often  serve  as  a  vehicle  for  final  reports  of  work  performed  at 
NIST  under  the  sponsorship  of  other  government  agencies. 

Voluntary  Product  Standards  —  Developed  under  procedures  published  by  the  Department  of 
Commerce  in  Part  10,  Title  15,  of  the  Code  of  Federal  Regulations.  The  standards  establish 
nationally  recognized  requirements  for  products,  and  provide  all  concerned  interests  with  a  basis 
for  common  understanding  of  the  characteristics  of  the  products.  NIST  administers  this  program 
in  support  of  the  efforts  of  private-sector  standardizing  organizations. 

Consumer  Information  Series  —  Practical  information,  based  on  NIST  research  and  experience, 
covering  areas  of  interest  to  the  consumer.  Easily  understandable  language  and  illustrations 
provide  useful  background  knowledge  for  shopping  in  today's  technological  marketplace. 
Order  the  above  NIST  publications  from:  Superintendent  of  Documents,  Government  Printing  Office, 
Washington,  DC  20402. 

Order  the  following  NIST  publications  -  FIPS  and  NISTIRs-from  the  National  Technical  Information 
Service,  Springfield,  VA  22161. 

Federal  Information  Processing  Standards  Publications  (FIPS  PUB) -Publications  in  this  series 
collectively  constitute  the  Federal  Information  Processing  Standards  Register.  The  Register  serves 
as  the  official  source  of  information  in  the  Federal  Government  regarding  standards  issued  by 
NIST  pursuant  to  the  Federal  Property  and  Administrative  Services  Act  of  1949  as  amended, 
Public  Law  89-306  (79  Stat.  1127),  and  as  implemented  by  Executive  Order  11717  (38  FR  12315, 
dated  May  11,  1973)  and  Part  6  of  Title  15  CFR  (Code  of  Federal  Regulations). 
NIST  Interagency  Reports  (NISTIR)-A  special  series  of  interim  or  final  reports  on  work 
performed  by  NIST  for  outside  sponsors  (both  government  and  non-government).  In  general, 
mitial  distribution  is  handled  by  the  sponsor;  public  distribution  is  by  the  National  Technical 
Information  Service,  Springfield,  VA  22161,  in  paper  copy  or  microfiche  form. 
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